It could just as well be “there are no updates available for the packages on this image”. One of those assertions for example is “there are no packages with vulnerabilities present”. The role itself has an Inspec profile associated with it, the logic being that “if you apply this role to any image, the resulting state should be the following”, then we make assertions about the state of the image. This involves taking the base AMI we want to build off (usually from the marketplace), then applying our desired configuration to it, via a well-maintained, semantically versioned and peer-reviewed Ansible role. The packer templates which are shared with people, as you want to do, use these base images and do not need to run any updates. Discovering this during a deploy pipeline of an actual workload is unadvisable, so we (the SREs) like to discover it before the developers do. It is true that sometimes applying automatic updates can result in flaky bakes - either the process takes too long and subsequent tasks time out, or there is some broken package which breaks everything. This is where we apply automatic updates, through a pipeline with tests associated. We maintain a “common” image upstream that all workloads are built off. For what it’s worth, I will share my experience with this, perhaps it will help inform your decision.
0 kommentar(er)
