A docker image registry is used to store docker images and maintain their versions. Container runtime engines such as Podman, Containerd, CRI-O, rkt, etc are typically used to the push and pull images using their respective commands. Most of these runtimes have a way to create and maintain a local registry for the machine on which they are installed. However when sharing images between different machines, we need a centralized repository where one can push and pull images. There are lot of PaaS registry services are available in the market already. However, sometimes you may want to have your own personal/private registry where you can control what images are available for your runtimes.Read More »
By default, Docker and Container uses UTC timezone. When container engines like Podman, Docker or CRI-O run containers, they pull down the specified OCI image from a container registry. The container image is usually built with a hardcoded link from /etc/localtime to one timezone. Once the image is pulled, the container engine just launches the container based on the hardcoded time zone. This means that your container running in London could be reporting that it is running in New York or Singapore, depending on where the image was built. Depending on your application and sometimes to meet certain audit requirements, it might be necessary for you to control the timezone in the containers.Read More »
AWS Key management service (AWS KMS) is a service offering from AWS to host and manage master keys, which are used to encrypt your data stored in other AWS services. AWS Elastic Container Registry (AWS ECR), by default, store images in the AWS S3, which uses AES-256 as server side encryption to protect the data stored at rest. However, some compliances such as HIPAA may warrant you to not only encrypt the data at rest, but also using specific encryption protocols. Using AWS KMS in either AWS managed or Customer Managed Keys (CMKs), allow one to be compliant with such regulations. In this blog post, we’ll discuss how we can enable the same for ECR images.Read More »
In the last blog post, we discussed about Amazon’s docker container image repository service, Elastic Container Registry (ECR). We learned how to create ECR, push and pull images and other basic operations. In this blog post, we’ll discuss about advanced features such as scan on push, lifecycle policies, etc. We’ll learn what these features are about, and how to turn them on or off.
Image tag Mutability
You can configure a repository to be immutable to prevent image tags from being overwritten. After the repository is configured for immutable tags, an
ImageTagAlreadyExistsException error is returned, if you attempt to push an image with a tag that is already in the repository.
Amazon Elastic Container Registry or ECR is one of the services hosted by Amazon Web Services (AWS). ECR provides both private and public repositories for storing container images. It integrates well with AWS CLI to push, pull and manage Docker images, Open Container Initiative (OCI) images, and OCI compatible artifacts. Both public ECR and private ECR, provides almost same features. However private ECR, as the name indicates, provides more security features for enterprises as all communication needs to be authenticated first. This is a first one in series of blog posts on the Amazon ECR, where we’ll cover the basics of getting started. In later blog posts, we’ll discuss how to operate and utilize various features in ECR, cover some security and monitoring considerations and some automation as well.Read More »
Over the last few years, adoption of Docker and Kubernetes has grown in leaps and bounds. Vast majority of developers is developing microservices and deploying them into containers. One of the most important aspect that people do not realize is that, the containers needs to be lightweight in nature. Also, while building containers, one needs to account for certain aspects like reducing build time while doing incremental builds, produce images in consistent ways, performing clean builds, maintain them properly, etc. To achieve all this, one needs to follow certain practices while writing Dockerfiles.
Read More »
Since in last post, we discussed on how to run Azure Pipelines agents as docker containers and configure them accordingly, the next step would be to run them on the Kubernetes platform. This kubernetes cluster can be on-premise and/or cloud and could be self managed or managed by the cloud service provider itself.
One of the reasons you may want to run them on Kubernetes is because you want better utilization of your kubernetes cluster. Another reason might be to leverage your existing knowledge of the kubernetes platform and work on it. Another reason would be to not use Microsoft hosted agents, as by default you would get only 1800 minutes of agent time to utilize, for free accounts.
Read More »
To run the build or deployment jobs in Azure DevOps or Azure Pipelines (formerly known as TFS and VSTS respectively), an agent is required. Microsoft provides the different types of the agents and they are hosted and managed by Microsoft only. However, it is advisable to host your own private agent for various reasons other than the cost. Microsoft provides the facility of installing agent on various OS’es like Windows, Linux, Mac OS etc. They have done a good job in terms of documentation, however you still need to perform few steps in order to set it up correctly.
Read More »