By Martin Albisetti, Senior Architect
The model shift to image-based deployments
In a previous post I covered why, once you decide to move to the cloud, you will likely also want to switch to image-based deployments (also called “immutable infrastructure”). This is because the way IaaS and PaaS infrastructure is designed and maintained is different than the way you managed servers in your data center. If you don’t make this switch, you will encounter a host of challenges that will likely result in poor serviceability and, ultimately, frustration on your part.
For example, clouds give you elasticity so you can use resources on-demand and scale up and down as needed over time or for small spikes in usage throughout the day. But to gain this, you must give up relying on the stability of each individual server or instance. In the cloud, you will find yourself spinning up new servers a lot more often than you did in the data center (some auto-scaling scenarios might be doing this several times an hour), so time-to-serve is crucial. And if you intend to do server configuration after they’ve booted, you can expect many minutes of wait time – perhaps even in the 30-minute range – before you can start serving requests. There’s also the risk factor that moving bits around on a system and downloading from different sources on the internet will tend to be flaky, and these processes might fail more often than you’d like them to and need to be restarted from scratch.
What we built into Bitnami Stacksmith to help you with the shift
In order to be able to do image-based deployments, building an image needs to be easy, repeatable and fast. This is because now (in the image-based deployment world), incorporating an update means creating an entirely new image, not, as was the case in your data center, deploying only the component that changed.
Stacksmith is one of the easiest ways to create a deployable image. Stacksmith will not only take care of all the underlying work needed to build an image, but it also produces a target-specific deployment template – a Helm Chart, AWS CloudFormation Template, or Azure Resource Manager (ARM) Template - so the output is immediately deployable.
Whether using the UI or the API, Stacksmith carefully narrows the inputs it takes, so at the end of the process you not only get a built image in your own cloud account, but, to the extent possible, a guarantee that the process will be reproducible tomorrow, or in 6 months.
Stacksmith also makes it incredibly easy to rebuild your image to incorporate updates - it is exactly one button click away.
The other crucial area where Stacksmith provides real value here is with its approach to monitoring for updates. We automate this process as well, so you don’t have to spend your time monitoring trusted sites manually.
Stacksmith approach to maintenance - focus on updates, enhance with CVEs
When a new security issue hits the press, the conversation typically hinges around a CVE number and, if it’s disruptive enough, a codename. It’s important to understand the issue that was reported, as it’s common for issues to only affect specific scenarios that may not be yours.
However, when we built Stacksmith, we instead focused on updates first. It’s rare for you to be able to mitigate issues without updating the software involved, so when designing and building the tool we made sure we provided a really solid way of tracking system updates as well as making them trivial to apply.
There’s also the occasional update that fixes an issue that’s not strictly security-related, but due to unforeseen circumstances requires certain packages to be updated in order to keep functioning properly. Kernel updates to run well on top of fast-changing cloud providers and tls certificates come to mind.
Then, on top of updates, we’ll layer CVEs to let you understand how important it is to apply the updates, what your risk exposure is, and be able to track and mitigate security issues across hundreds of applications from one place.
System package updates and language runtime dependency updates
Traditionally (and generally), dependencies in the Linux world were sourced from the distribution’s repositories. Sourcing your updates from the system package like this meant you didn’t have to worry about whether all the software components fit and worked together, and gave you assurance that licensing and security concerns were taken care of by deep experts in those communities.
But as the pace of change in open source software started to accelerate, with more contributors, changes, and new projects created daily, the Linux distributions could no longer keep up with certain parts of the ecosystem.
Applications started using more and more dependencies from their language runtime repositories, and more importantly, those are the dependencies developers tend to care about and update more frequently. And these dependencies are easier to track, as they are part of the normal development workflow.
So when we designed Stacksmith, we decided to treat these two types of updates separately, and focus first on the system package updates, as these are less accessible to developers and typically the ones that get neglected.
How Stacksmith handles updating
For every image that gets built, Stacksmith extracts the package manager’s state at the very last step of the build process, and captures all the system dependencies that were installed - with their exact version numbers as well as which repositories were used to install them. This information forms what we refer to as the components manifest - a comprehensive and detailed listing of all of the components of your application package (this manifest is also an incredibly valuable tool for auditing, but that is a topic for another post).
From then on, Stacksmith tracks the relevant repositories, compares them to the components manifest, and records whenever an update is available. Stacksmith then alerts you to the availability of these updates through the product UI, and, optionally, notifies you or automatically kicks off a new image-build process that incorporates the updated packages.
 |
| Stacksmith UI showing a list of packages that have updates available |
It is important to note that I am talking about tracking both the default dependencies that are required for your application to run on the target platform, as well as dependencies that get brought in later. For example, to offer greater flexibility during the image creation process, Stacksmith lets you define actions and dependencies via the use of scripts, which get invoked at the moment the package is being built, booted, or even run for the first time. To Stacksmith, these are all key to the goal of creating a final, deployable image, so the repositories that get added at this phase are also tracked. Stacksmith goes to great lengths to ensure we are tracking everything that’s important to keep each image updated.
Throughout all of this, there’s very little you need to learn or understand about how images are built. As a user, you deal with the end result, which is a familiar bootable image that will have your software installed and be ready to work.
As you can see, one of our goals at Bitnami is to keep lowering the barrier of adoption of cloud-native approaches to software development and deployment. Learn more at bitnami.com/stacksmith. And expect to see additional features get added to Stacksmith that lower the barrier to adopting Kubernetes and public clouds.