The Apache Mesos page describes that Mesos enables task isolation through "Linux Containers". What container technology is this, LxC?
Does "native Docker support" mean that the above container technology can we swapped to Docker? What does it mean when Mesos states that Docker can be used either as an Executor or a Task? If Docker is used as an Executor, doesn't it mean that there should be a "Docker Framework" somewhere?
Actually mesos supports several containerizer:
Docker (see http://mesos.apache.org/documentation/latest/docker-containerizer/)
Mesos Containerizer (default)
Custom External Containerizer (see http://mesos.apache.org/documentation/latest/external-containerizer/)
Native docker support in my understanding refers to the support for many of the docker specific options (see for example the configuration options here: http://mesos.apache.org/documentation/latest/configuration/)
Short Update: Please note that option 3 (external containerizer) is deprecated.
Know what a Virtual Machine (like VMWare or Virtual PC) is? Docker is something like a much more 'lightweight' virtual machine (of course more superior, but let's keep it simple here). Further information can be found here http://en.wikipedia.org/wiki/Docker_%28software%29 and here https://www.docker.com/.
Related
I have come across the word IaC many times while learning DevOps and when I googled it to know what it is it showed that it used code as it is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. So is docker also a infrastructure as code technology because it virtualizes an OS to handle multiple workloads on a single OS instance? Thanks in advance
I'm not sure exactly what you are asking, but Docker provides infrastructure as code because the Docker functionality is set via Dockerfiles and shell scripts. You don't install a list of programs manually when defining an image. You don't configure anything with a GUI in order to create an environment when you pull an image from Docker hub or when you deploy your own image.
And as said in another answer, Docker is not virtualization, as everything is actually running in your Linux kernel, but with limited resources in its own namespace. You can see a container process via htop in the host machine, for instance. There's no hypervisor. There's no overhead.
I think you misunderstud the concept, because neither Docker is an hypervidor nor containers are VMs.
From this page: https://www.docker.com/resources/what-container
A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings.
Container images become containers at runtime and in the case of Docker containers - images become containers when they run on Docker Engine.
Containers are an abstraction at the app layer that packages code and dependencies together. Multiple containers can run on the same machine and share the OS kernel with other containers, each running as isolated processes in user space.
This may be the stupid question.
Does Hyperledger Fabric require Docker for its operations.
I'm just wondering that Docker is needed only if we need to run Fabric peer, orderer or couchDB as virtual machine in the same physical machine. I think Docker might not be necessary if we install those sofwares (peer, order, couchDB, etc) natively on the separate and same server.
Thank you.
Just so this point does not go unnoticed, while you do not need to run the peer in a Docker container, endorsing peers (the ones which run chaincode) need access to a Docker daemon (ideally on the same host). Chaincode is currently only deployed via Docker containers.
The question as to whether Docker is required to run a peer, orderer, fabric-ca, etc. depends on what effort you are willing to expend.
The Hyperledger Fabric community publishes stable, tested Docker images for X86, PowerPC and s390 (mainframe) architectures for each of its releases. These images are based on Ubuntu.
To use the Hyperledger Fabric published release images, you need Docker and some form of orchestration support. For sample use cases, we provide some simple Docker Compose definitions. Hyperledger Cello and other provisioning platforms such as the IBM sandbox, provide kubernetes helm charts.
It is possible to build the binaries outside of their Docker images without modification of the source. However, if you wish to build for an alternative OS (e.g. Windows, RHEL or CENTOS, etc) then you will need to modify the build process. However, it can and has been done. Suggest you reach out to the hyperledger-fabric#lists.hyperledger.org mailing list to see if any in the community that have built for alternative deployment will share their work.
Starting HLF 2.0 things have changed. According to documentation, chaincode can be in 'external containers' also.
https://hyperledger-fabric.readthedocs.io/en/release-2.0/cc_launcher.html
Yes, it is the second heading on the prerequisites page at http://hyperledger-fabric.readthedocs.io/en/latest/prereqs.html
Docker and Docker Compose
I've read multiple articles how to do this, but I can't figure out what the benefits are under macOS.
From my point of view, you can run Docker natively on macOS using Docker Community Edition (boot2docker+Kitematic). What does it's give me for running from Vagrant, mobility?
My standard day to day development work is carried out in Docker For Mac/Windows as they cover about 95% of what I need to do with Docker. Since they replaced Docker Toolbox/boot2docker and made the integration to the OS pretty seamless I have found very few reasons to move over to another virtual machine. The two main reasons I see for using Vagrant or standalone VM's now are for VM customisation and clustering.
VM Customisation
The virtual machines supplied by Docker Toolbox, Docker for Mac/Windows are pre packaged cut down Linux distros (TinyCore and Alpine) that are largely ephemeral, except for the Docker configuration so you don't get much say in how they work.
Networking
I deal with a number of custom network configurations that just aren't possible in the pre packaged VM's, largely around having containers connected to routable networks rather than using mapped ports.
Version Control
Occasionally you need to replicate server environments that run old versions of the Docker daemon, or RHEL servers using devicemapper. A VM let's you choose the packages to install.
Clustering
Building a swarm, or branching out into Mesosphere/Kubernetes will require multiple VM's. I tend to find these easier to manage and build with Vagrant rather than Docker Machine, and again they require custom config inside the VM.
I think the words "Provider" and "Provisioner" sound very similar which may lead to confusion especially among beginners confronted with documentation where both terms are mixed up or used synonymous (already seen on the net). Even more confusing it gets when beginners see Docker as Provider and Docker as Provisioner mentioned on Vagrant´s website.
So this question is actually about three things:
What is a Vagrant Provider?
What is a Vagrant Provisioner?
How does Docker fit in here?
What could be a typical use case for Docker as Vagrant Provider?
What could be a typical use case for Docker as Vagrant Provisioner?
I appreciate explanations, examples and links for further reading which illustrate things clearly (even for noobs).
The underlying virtualization solutions are called providers. To work with Vagrant, you have to install at least one provider (e.g. Virtualbox, VMWare)
Provisioning in Vagrant is the process of automatic installation and configuration of the system within during $ vagrant up and the tools to perform this operation are called provisioners (e.g. Shell scripts, Chef, Puppet).
Provider vs Provisioner
Vagrant uses Providers such as hypervisors (e.g VirtualBox, Hyper-V) or Docker to create and run virtual environments. Vagrant uses Provisioners (e.g Ansible, Puppet, Chef) as configuration tools to customize these environments, e.g carrying out installs and starting apps.
How does Docker fit in?
If a hypervisor is used as a Provider, the environment that is created is a virtual machine based on a self-contained image of an operating system environment as provided by a “Vagrantbox” (aka “box”). The box is utilized by Vagrant to create a dedicated kernel and set of operating system processes for the virtual machine.
If Docker is used as a Provider and Docker is available on the host system, Vagrant manages and runs containers directly on the host system. Here Vagrant is not actually building and managing a virtual machine but rather is working with the Docker engine running on the host to manage and build Docker containers.
We're thinking about using mesos and mesosphere to host our docker containers. Reading the docs it says that a prerequisite is that:
Docker version 1.0.0 or later needs to be installed on each slave
node.
We don't want to manually SSH into each new machine and install the correct version of the Docker daemon. Instead we're thinking about using something like Ansible to install Docker (and perhaps other services that may be required on each slave).
Is this a good way to solve it or does Mesosphere/DCOS or any of Mesos ecosystem components have other ways of dealing with this?
I've seen the quick intro where someone from Mesosphere just use dcos resize to change the cluster size on the Google Cloud Platform. Is there a way to hook in to this process and install additional services on the (google) container when it has booted? Or is this something we should avoid and instead just use a "pre-baked image"?
In your own datacenter using your favorite configuration tool such as ansible, salt, ... is probably a good choice.
On the cloud it might be easier to use virtual machine images providing docker, so for example dcos on aws uses coreOS which comes with docker out of the box. Shouldn't be too difficult with Ubuntu either...