Official .NET Docker images support three Linux distors:
Debian - 3.1.201-buster
Alpine - 3.1.201-alpine
Ubuntu - 3.1.201-bionic
I didn't find much in the documentation:
Which and why should prefer one over another? Since AKS nodes are Ubuntu based they all work. So which should I select?
Since they are all base don the same architecture, I would say that the deciding factor should be
1) which image is the smaller (or not as big)
2) which comes with built in binaries that are useful to your need. (e.g. the alpine base normally handles DNS lookup differently when using nslookup)
e.g : https://github.com/gliderlabs/docker-alpine/issues/476
In the end, it is up to you, what is important, you pick one that you are comfortable with and one with you trust more with respect to CVE and security updates to be available the fastest.
Related
I'm learning about Docker architecture.
I know that images are made to run applications in containers (virtualization). One thing that I stepped on was that there is an entire community hub for posting images. But what is actually the point of doing that?
Isn't the idea of images contain a very specific enviroment with very specific configurations that runs very specific applications?
The idea of images is to have a well-defined environment. The images by the community serve mostly as building blocks or base images for your own, more specific, images. For some applications, you can use an image as-is with maybe a little configuration parameters, but I would guess the more common use case is to start building your specific image based on an already existing, more general image.
Example:
You want to create an image with a certain Java application. So you look for an image that already has the Java version you want, and create an image based on that more general image.
You want to test your application on different OS versions (maybe different Linux versions). So you create a couple of images, each based on a different base image that already has the OS installed that you are interested in.
I am trying to understand Docker and its related core concepts, I came to know that there is concept of images which forms the basis of container where applications run isolated.
I also came to know that we can download the official images from docker hub, https://hub.docker.com , part of screen shot below:
My question is:
Do respective company create special/custom made OS (the minimal, for example we can see ubuntu image) for docker? If so, what benefit these companies get in creating these custom made images for docker?
One could call them custom images, however, they are just base bare images which are to be used as a starting point for your application.
They are mostly built by people who works at Docker and they are trying to ensure some guarantee of quality.
They are stripped of unnecessary packages in order to keep the image size to a minimum.
To find out more you could read this Docker documentation page or this blog post.
How are they functioning differently?
Which features of the kernel are they using?
You can read all about it in this link
Basically, my impression is that rkt takes pride in being image-agnostic (meaning you can run images that were built using docker or other container engines) and contain less overhead than docker does. This is a nice picture to describe the differences between the two (taken from the link I've attached) -
I know we can create docker images using ansible. I'm learning and doing POC work.
I'm trying to find what are the pros/cons of creating a docker image using Ansible.
Would like to hear if you have played and found any issues/solutions with creating docker images (NOT deploying docker images) using ansible?
Also, are there any good reasons not to create docker images using Ansible?
It can be a good choice.
If an agentless system is good enough for your needs, keeping your Docker images lightweight (by not having any agent in them) is a reasonable thing to desire.
If your ops team uses Ansible, using the same playbooks in configuring your Docker images (used for dev/test) as for production is desirable.
If your production environment uses Docker in the manner in which it's intended to be used, then you have reduced need for complex logic around maintenance and upkeep of existing systems, which makes Ansible a better option.
That said, I also have a laundry list of complaints about Ansible -- particularly, in places where its DSL is poorly designed in ways that make automating generation of playbooks error-prone, and places where functionality present in some of its competitors (albeit not particularly relevant to Docker image generation) was designed in only as an afterthought.
No tool is perfect; the decision in terms of what meets your needs and fails only in ways you find acceptable needs to be made in the context of your own use cases.
I have a questition about the best pratices on using docker in production.
In my company we use SLES12 as host os. Should we use SLES also as base for our docker containers?
In my opinion SLES image is too big to follow the ddocker recommendation for small base images.
My questition is: Has anyone experience in using docker in production with different host and container os? Are there any disadvantages if we use a small debian/ubuntu base image for our containers? (overhead, security, ...)
I agree with your assessment that for dockerized applications, smaller base images are preferred. This will save on disk space, reduce network transfer, offer a smaller software surface to worry about security vulnerabilities and general complexity. To my knowledge different host/container distributions is the norm and when they align it's more of a coincidence than an intentional design. Since the way you interact with the host OS and the container are so very different, even if they were identical, you procedures for keeping things patched would be different. That said, depending on your staff skill set, sticking to the same package manager ecosystem (rpm vs deb) may have some benefit in terms of familiarity of tooling, so finding a small base RPM distro might be a good choice.