Recently, I remembered a situation when I was in elementary school and visited a friend at his house. At some point, his mother wanted us to go to a neighbour and ask to borrow some eggs. We went a few houses down, opened the garden gate, entered through the door to the house, and arrived in the kitchen calling out for the person. But no one was at home, so we left and returned without eggs.
Keep your doors locked
It felt strange to enter a house with no person being at home. However, it was normal at that time not to lock doors, and probably it is still normal today in some areas. In contrast, most of us agree with locking all doors when out of the house. Usually we feel compelled to lock our doors – when at home, or leaving our cars, or when we’re the last person out of the office.
A friend of mine complained about applying software updates and noted: “Imagine if security issues would not be a problem, we could keep running our machines in their original configuration almost forever.” In fact, in a world without security threats, even the oldest machines with their software could keep running once properly set up. Maybe at some point, they would be replaced for other considerations, such as for saving energy or server space.
Updating is the routine
Unfortunately, we do not live in such a world. And, although engineers invent and develop new functionality, software updates are very necessary for ensuring that our doors stay properly locked.
We see it everywhere: a proprietary software vendor offers patches for its operating system on a monthly basis. An electric car maker appears to update the firmware of their cars sometimes even multiple times a month. (There are websites by fans tracking this publicly.) Also, in the Debian package ecosystem, we see many packages with similar update frequencies. Applying these updates is often necessary, not only for bringing new features to the users, but for keeping our doors properly locked.
And that applies in particular for server applications, because servers stay connected on the network, making it more important to keep doors locked than with desktop computers or notebooks.
Simplify complex updates with the Charmed Operator Framework
A complex application usually consists of several elements – for example, a common setup includes a Web server front-end and a database server or logging facilities. For each self-contained software element of server applications, operator software covers the required operational tasks, including updating. If the update routine for each application element is implemented as software, as operator, the obvious advantage is less total effort and more reuse. Whenever a Web server for example is being used for an application setup, the same update procedure in a Charmed Operator will ensure proven and reusable update runs.
Operator Framework: Channels for Releasing and Updating
The Charmed Operator Framework defines a proven versioning model for updating the operator software itself. An important distinction lies in updating the Charmed Operator and the version of the application it manages. A developer of Charmed Operators needs to update the Charm implementation from time to time – for example, for major updates of the application. The tool for building and updating is named charmcraft. Of course, charmcraft is installed as a snap, executed with a quick snap install charmcraft –classic.
One fundamental element for releasing updates of Charmed Operators is that they are not published for the public until they are released to a channel. A channel is an already proven concept from the snap package management: releasing a Charmed Operator can be targeted to a channel. Accordingly, a user who has deployed a Charmed Operator from a particular channel will then see updates from that channel – so a channel for stable releases can be targeted for deployment automation. By this structure, updates of Charms can be separated for different use cases or users. A channel is a triple with the following elements:
track/risk/branch
where track and branch can be optional. Let’s have a brief look at the three elements:
The risk element can have the values stable, candidate, beta, or edge. A deployed Charm from the channel with risk value stable will accordingly see updates from the stable channel.
The risk element helps the developer to stage updates (candidates) or to safely continuously release Charmed Operators from CI-based builds in a devops automation environment (edge). The developer can set the track value for denoting a version of the charm, which could reference the application version. Last but not least, the branch is a field for denoting a special variant.
For example, the command
charmcraft release mycharm –channel=stable
will release a charm as the latest release to stable. This structure provides updates for Charmed Operators in a clean and structured way. And this helps keep our doors locked.
Further reading
- Read more about channels with Charms
- Beyond Helm and Kustomize: the Future of Kubernetes Apps
- From storage management to AI/ML stacks, discover all available operators
- Get started with the Charmed Operators SDK
Discover more from Ubuntu-Server.com
Subscribe to get the latest posts sent to your email.
