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.
Related
I am new to Docker and want to learn the ropes with real-life challenges.
I have an application hosted on IIS and has dependencies over SQL Express and SOLR.
I want to understand the following:
Is it possible to have my whole set-up, including of enabling IIS,
SQL, SOLR and my application in one single container?
If point 1 is feasible, how should I start with it?
Sorry if my questions are basics.
It is feasible, just not a good practice. You want to isolate the software stack to improve the mantainability (easier to deploy updates), modularity (you can reuse a certain component in a different project and even have multiple projects reusing the same image) and security (a software vulnerability in a component of the stack will hardly be able to reach a different component).
So, instead of putting all together into the same image, I do recommend using Docker Compose to have multiple images for each component of the stack (you can even pull generic, up-to-date images from Docker Hub) and assemble them up from the Compose file, so with a single command you can fire up all the components needed for your application to work.
That being said, it is feasible to have all the stack together into the same Dockerfile, but it will be an important mess. You'll need a Dockerfile that installs all the software required, which will make it bulky and hard to mantain. If you're really up for this, you'll have to start from a basic OS image (maybe Windows Server Core IIS) and from there start installing all the other software manually. If there are Dockerfiles for the other components you need to install and they share the same base image or a compatible one, you can straight copy-paste the contents into your Dockerfile, at the cost of said mantainability.
Also, you should definitely use volumes to keep your data safe, especially if you take this monolithic approach, since you risk losing data from the database otherwise.
TL;DR: yes, you can, but you really don't want to since there are much better alternatives that are almost as hard.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am coding in a few different languages/technologies. Actually to be honest, I am only messing around, playing with golang, node.js, ruby on rails, etc.
But now I want to jump on the Docker bandwagon as well, but I am not sure what the benefits would be and if I should put in the effort.
What is the best practise in using Docker for development environments? Do I set up a separate container for each language or technology I dabble with? Or are containers overkill and I should just set up one VM (Linux VM on Windows host) where I do all the development?
How do you guys use Docker for development work?
You should definitely go ahead and do that as is the best approach to follow, even if you share volumes between containers, and avoid setting up different VMs if you have the necessary hardware-power in your workstation and do not need to distribute your environment on different workstations.
At my current company, I'm the guy responsible for setting up all the development environments among other things. We have a few monolithic applications but we're quickly decoupling multiple functionalities into separate micro-services.
How we're starting to manage that is, every micro-service code repository has everything self-contained, that being docker-compose files, with a makefile for the automation, tests, etc.
Developers just have to install docker-toolbox on their Mac OS X, clone the repo and type make. That will start the docker compose with all the links between the containers and all the necessary bits and pieces (DBs, Caches, Queues).
Direct link to the Makefile: https://github.com/marclop/prometheus-demo/blob/master/Makefile.
Also if you want to avoid setting up all the containers there's a few alternatives out there, for example Phusion's one: https://github.com/phusion/baseimage-docker.
I hope this answers your questions.
You shouldn't use Docker for your development environments, use regular vm's like VirtualBox for that if you want complete separation.
Docker is more suited for delivering finished code somewhere, e.g. to a staging environment.
And the reason is that Docker containers are not ideal for persisted state unless you mess around with sharing volumes.
The answer to this is inherently subjective and tied to how you like to do development. It will also be tied to how you want to deploy these in a testing scenario.
Jonas is correct, the primary purpose of Docker is to provide finished code to a staging/production environment HOWEVER I have used it for development and indeed it may be preferable depending on your situation.
To whit - lets say you have a single virtual server, and you want to minimize the amount of space you are using for your environment. The entire purpose of Docker is to store a single copy of the Linux kernel (and base software) and re-use them in each docker instance. You can also minimize the RAM and CPU usage used for running the base Linux "pieces" by running the Docker container on top of Linux.
Probably the most compelling reason (in your case) to use Docker would be to make finding the base setup you want easier. There are plenty of pre-made docker containers that you can use to build your test/dev environment and deploying your code after you are finished to a different machine is WAY easier using Docker than VMWare or Virtual Box (yes, you can create an OVF and that would work, but Docker is IMHO much easier).
I personally used Project Photon when I was playing around with this, which provided a very easy way to setup the base Docker setup in a VMWare environment.
https://blogs.vmware.com/cloudnative/introducing-photon/
The last time I used Docker was for an assignment in one of my classes where I was having to play around with MongoDB on a local instance. Setting up MongoDB would have been trivial on either (or both) Windows or Linux, but I felt the opportunity to learn Docker was too much to pass up. In the end, I feel much more comfortable now with Docker :)
There are ways of backing up Containers, which can (as Jonas pointed out) get kind of messy, but it isn't outside the realm of a reasonably technical individual.
Good Luck either way you go! Again, either way will obviously work - and I don't see anything inherently wrong with either approach.
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.
I am trying to learn both Dart and GCE. I already created a server at GCE, but I don't know how to install Dart since I can only use Linux commands on the Debian server.
This is mostly about Dart on AppEngine:
You should be able to find all information here https://www.dartlang.org/cloud/
I did it using the instructions from this page and the linked pages at the bottom.
The discussions here https://groups.google.com/a/dartlang.org/forum/#!forum/cloud provide some useful bits too.
Dart on Compute engine:
Here is a blog post that covers it pretty good http://financecoding.github.io/blog/2013/09/30/getting-started-with-dart-on-compute-engine/ but some things have changed since this was written.
There are docker images https://github.com/dart-lang/dart_docker ready to execute Dart scripts.
Just search for information how to use Docker images with GCE and you should be fine (there should already be a lot available)
Please ask again if you encounter concrete problems.
Dart on AppEngine runs as Managed VM. Managed VMs work differently than real AppEngine VMs that run 'native' supported languages like Java, Python, and Go. Managed VMs are in fact Compute engines but managed by AppEngine. This means they are launched and shut down depending on the load (and depending on some basic configuration settings in app.yaml and also depending on payment settings) while Compute Engines instances are basically always on. You have to manage yourself when instances should be added/removed depending on the load. There is Kubernetes which is a handy tool to make this easier but you have to actually manage your instances. Besides from that there is not much difference between Managed VMs and Compute Engine instances. A difference to native AppEngine is that you can add any libraries and also binaries to Managed VMs like to CE.
There are pricing differences but I don't know details about this myself yet