To become net-zero by 2050, as Euronav has committed to doing, they must look for solutions that will help them to optimize the management of their vessels, including their fuel consumption. To do this, Codit is helping them to build a platform on which we can collect multiple metrics coming from the machinery that runs on oil tankers. This information is used by an application that runs on the vessel and allows the crew to see how all the engines, cargo-tanks, bunker-tanks, navigation systems and weather stations are behaving, so they can report this to operators working on the shore. The platform is designed with a microservices architecture, which means that it consists of multiple components that are self-contained and can be deployed separately.
How to Get the Container Images Onboard
All the components that make up this platform are packaged as containers, which allows us to run the components both in the cloud and on the vessel. A lightweight Kubernetes (k3s) cluster is present on the vessel, which orchestrates the containers that are deployed there.
This means that we need to get those container images onboard each ship. Although the Euronav vessels are 95% of the time connected with the Internet, getting the container images onboard a vessel can be quite a hassle, as the connectivity-percentage doesn’t tell us anything about the connection quality.
In our setup, we have multiple CI/CD pipelines that are used to build the different components and ultimately, each pipeline will push a container image to an Azure Container Registry. When we want to deploy or upgrade the application to a vessel, we have an additional pipeline (running on the vessel) that makes sure that the correct version of all the containers that make up the solution are pulled and used:
It’s at the moment that we want to deploy to the vessels that we run into problems, for there are high network latency, connection drops and various other reasons that could cause the deployment to fail.
Using a Connected Registry
In a first attempt to solve the deployment issues we ran into, we decided to enable geo-replication on our Azure Container Registry. This helped us in certain situations but not all. When a vessel is close to shore in a region where we have deployed a replica we could benefit from this, but for vessels that are in the middle of the ocean, nothing changes.
In February 2021, we got in touch with the Microsoft ACR product team and explained our problem. It turned out that Microsoft was in the process of creating a ‘connected registry’ and we were given the opportunity to participate in the private preview, a chance we gladly accepted. At Ignite 2021, Microsoft announced the public preview of the connected registry feature.
The ‘connected registry’ feature allows us to install an on-prem container registry on the vessels, which is linked with an Azure Container Registry instance. This means that whenever a container image is pushed to the Azure Container Registry living in the cloud, the connected registry will import that image as well. Eventually, the container images that we build will be available on the vessel.
This helps us with deploying our application to a vessel, as new versions of components are not immediately used onboard. Several days or weeks pass before a new container can be deployed after it has been built, as the application is tested in a lab environment before we deploy it to a vessel. This gives the connected registry plenty of time to pull in the image before we actually trigger the pipeline that deploys the solution to the vessels.
With the connected registry, the setup looks like this:
Limiting the Number of Containers that are Pushed
In a continuous integration setup, we run our build pipelines multiple times a day. This means that we build and test our components, but it also means that we’re producing a lot of container images. All those images are pushed to an Azure Container Registry and if there are connected registries linked with that ACR, they will pull in those images as well.
This makes no sense, as we know that not all images built will make it to production. Actually, the majority of container images that we produce will never be used on a vessel.
To make sure that we do not transfer bytes unnecessarily over a satellite connection, we introduced yet another Azure Container Registry. This additional ACR acts as the ‘parent’ for all connected registries deployed on the vessels.
Since we have multiple environments (dev, test, acceptance, production), we assume that once an image makes it to the acceptance stage, the chances that this version will be used in production are significantly higher. Therefore, we decided to make sure that container images that are tested in the Acceptance environment are imported to the ‘parent’ ACR. This means that the connected registries that are deployed on the vessels can start pulling in this new version once it has been pushed to acceptance.
Conclusion
The connected registry of Azure Container Registry is an awesome feature that could help you to tackle issues you encounter with on-premise deployments, especially when network connectivity is not guaranteed.
If you want to learn more, have a look at this website, or get in touch!
Thanks for reading,
Frederik
Abonneer je op onze RSS feed