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.
Related
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.
Apparently OS distributions come in stripped down versions. E.g. ubuntu for docker is ~150MB which is quite small. But I don’t understand how can it be so small. Do they ship the most minimal functionality and expose fake APIs that delegate to the host kernel? How do they make it so small?
I understand that it is software shipped in some sort of binary format. In simple terms, what exactly is a docker-image? And what problem is it trying to solve? And how is it better than other distribution formats?
As a student, I don't completely get the picture of how it works and why so many companies are opting for it? Even many open source libraries are shipped as docker images.
To understand the docker images, you should better understand the main element of the Docker mechanism the UnionFS.
Unionfs is a filesystem service for Linux, FreeBSD and NetBSD which
implements a union mount for other file systems. It allows files and
directories of separate file systems, known as branches, to be
transparently overlaid, forming a single coherent file system.
The docker images сonsist of several layers(levels). Each layer is a write-protected filesystem, for every instruction in the Dockerfile created own layer, which has been placed over already created. Then the docker run or docker create is invoked, it make a layer on the top with write persmission(also it has doing a lot of other things). This approach to the distribution of containers is very good in my opinion.
Disclaimer:
It is my opinion which I'm found somewhere, feel free to correct me if I'm wrong.
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 recently deployed a tiny Haskell app with docker, using "scratch-haskell" as a base image.
Then I read about Unikernels and HALVM. And I got a little confused.
My docker container is about 6MB large. A Unikernel (with the same haskell app) would be roughly the same size I guess.
The Unikernel runs directly on the Xen hypervisor, whereas the docker Image (or general LXC) runs on a normal Linux distribution, which runs on bare metal.
Now I have the "choice" of running Linux with multiple minimal containers OR a Xen machine with multiple small Unikernels.
But what are the advantages and disadvantages of those two solutions? Is one more secure than the other? And are there any significant performance differences between them?
from http://wiki.xenproject.org/wiki/Unikernels
What do Unikernels Provide?
Unikernels normally generate a singular runtime environment meant to
enable single applications built solely with that environment.
Generally, this environment lacks the ability to spawn subprocesses,
execute shell commands, create multiple threads, or fork processes.
Instead, they provide a pure incarnation of the language runtime
targetted, be it OCaml, Haskell, Java, Erlang, or some other
environment.
Unikernels Versus Linux Containers
Much has been made recently of the advantages of Linux Container
solutions over traditional VMs. It is said by container advocates that
their lightweight memory footprint, quick boot time, and ease of
packaging makes containers the future of virtualization. While these
aspects of containers are certainly notable, they do not spell the end
of the world of the hypervisor. In fact, Unikernels may reduce the
long-term usefulness of containers.
Unikernels facilitate the very same desirable attributes described by
the container proponents, with the addition of an absolutely splendid
security story which few other solutions can match.
So if you want just run Haskell application Unikernels may work for you, and they should have even less overhead than docker (and docker overhead is very small anyway), but if your application will need some prepared environment, need to communicate with non Unikernels software docker is a better choice. I guess it is too early to say will Unikernels be useful or widespread or not, only time will tell.
Unikernals are great for things that are stateless. When you start needing disk access you are better off using Docker.
That's why all the "killer" apps for unikernals are statically configured kernels, like static web pages or software defined networking stacks.
There are many good explations heres a simple one :
Unikernel are VMs but specialized and optimized for the particular application.