I thought a major benefit of Docker was the ability to deploy a single unit of work (a container) that is cheap, lightweight, and boots fast, instead of having to deploy a more expensive and heavy VM that boots slowly. But everywhere I look (eg AWS, Docker Cloud, IBM, Azure, Google Cloud, kubernetes), deploying single containers is not an option. Instead, a single customer must deploy entire VMs that will run instances of the docker engine which will then host clusters of containers.
Is there any CaaS that allows you to deploy only as few containers as you need? I thought many cloud provider companies would offer this service, coordinating the logistics of which containers submitted by which customers to group together and distribute among the companies' docker engines. I see this service is unnecessary for those customers that will be deploying enough containers that a full docker engine instance is necessary. But what about those customers that want the cheap option of only deploying a single container?
If this service is not available, I see Docker containers as no cheaper nor lighter in weight than full VMs. In both cases, you pay for a heavy VM. The only remaining benefit would be isolation of processes and the ability to quickly change them.
Again, is there any cloud service available to deploy only a single container?
As far as I see here, the problem is the point of view of your approach, not Docker.
Any machine that runs a GNU-Linux distro can run the docker daemon and therefore, run your docker containers.
There are solutions like Elastic Beanstalk that allow you to deploy docker containers with a high level of abstraction, making your "ops" part a little bit easier.
Nevertheless, I wonder, how do you actually try to deploy your application? what do you mean with:
"Instead, a single customer must deploy entire VMs that will run
instances of the docker engine which will then host clusters of
containers."
?
For example, kubernetes is a framework that allows you to deploy containers in other machines, so yes, you have to have a Framework for that or, instead, use a Framework as a service as Elastic Beankstalk is.
I hope my answer helps!
Related
so I'm currently developing a distributed system with microservices and I'm running out of memory to run all of them in my laptop. I wonder how other people manage this situation. Is there a way to configure docker-compose to run some of them in a remote machine but keep behavior as if they were on my laptop (for inter-service communication)?
I know that I might achieve it with k8s but it seems to be so much burden for day-to-day development flow.
Any ideas?
well if it's about day to day development, then you can figure out only the most essential services to run on your system. even if with the most essential microservices you are getting out of memory then you know the answer that you can't run them all on your local machine, unless you increase your resources or you can try Docker swarm (similar to k8s but a bit easier).
docker swarm - you will need to create a cluster among multiple machines and you will be able to offload some of the services on the other machines within the cluster.
Also, you will need to do minor changes in your docker-compose file to run on the docker swarm.
Sorry for this question, but I just started with Docker and Docker Compose and I really didn't need any of this until I read that I need to use Docker Swarn or Kuebernetes to have more stability in production. I started reading about Docker Swarn and they mentioned nodes and clusters.
I was really happy not knowing about this as I understood docker-compose:
Is that I could manage my services/containers from a single file
and only have to run several commands to launch, build, delete, etc.
all my services based on the docker-compose configuration.
But now the nodes and cluster have come out and I've really gone a bit crazy, and that's why if you can help me understand this next step in the life of containers. I've been googling and it's not very clear to me.
I hope you can help me and explain it to me in a way that I can understand.
Thank you!
A node is just a physical or virtual machine.
In Kubernetes/Docker Swarm context each node must have the relevant binaries installed (Docker Engine, kubelet etc..)
A cluster is a grouping of one or more nodes.
If you have just been testing on your local machine you have a single node.
If you were to add a second machine and link both machines together using docker swarm/kubernetes then you would have created a 2 node cluster
You can then use docker swarm/kubernetes to run your services/containers on any or all nodes in your cluster. This allows your services to be more resilient and fault tolerant.
By default Docker Compose runs a set of containers on a single system. If you need to run more containers than fit on one system, or you're just afraid of that system crashing, you need more than one system to do it. The cluster is the group of all of the systems (physical computers, virtual machines, cloud instances) that are working together to run the containers. Each of those individual systems is a node.
The other important part of the cluster container setups is that you can generally run multiple replicas of a give container, and you don't care where in the cluster they run. Say you have five nodes, and a Web server container, and you'd like to run three copies of it for redundancy. Instead of having to pick a node, ssh to it, and manually docker run there, you just tell the cluster manager "run me three of these", and it chooses a node and launches the container for you. You can also scale the containers up and down at runtime, or potentially set the cluster to do the scaling on its own based on load.
If your workload is okay running a single copy of containers on a single server, you don't need a cluster setup. (You might have some downtime during updates or if the single server dies.) Swarm has the advantages of being bundled with Docker and being able to use Docker-native tools (docker-compose can deploy to a Swarm cluster). Kubernetes is much more complex, but at this point most public cloud providers will sell you a preconfigured Kubernetes cluster, and it has better stories around security, storage management, and autoscaling. There are also a couple other less-prominent alternatives like Nomad and Mesos out there.
Is there a reason to use docker-swarm instead of docker-compose for deploying a single host in production?
I'm currently rewriting an existing application. My predecessors set up the application using docker-swarm. But I do not understand why: the application will only consist of a single host running a couple of services. These services will only supply some local information on the customer network via a REST-Api to a kubernetes cluster (so no real load or reason to add additional hosts).
I looked through the Docker website and could not find a reason to use docker-swarm to deploy a single host, apart from testing a deployment on a single host dev environment.
Are there benefits of using docker-swarm compared to docker-compose regarding deployment, networking, etc...?
Docker Swarm and Docker Compose are fundamentally different animals. Compose is a build tool that lets you define and configure a group of related containers, whereas swarm is an orchestration tool that manages multiple docker engines in a way that lets you treat them (somewhat) as a single unit. Swarm exposes an API that is mostly compatible with the Docker Remote API, which allows existing applications to use Swarm to scale horizontally without having to completely overhaul the existing interface to the container engine.
That said, much of the functionality in Docker Compose that overlaps with Docker Swarm has been added incrementally. Compose has grown over time, and the distinction between the two has narrowed a bit. Swarm was eventually integrated into the Docker engine, and Docker Stack was introduced, allowing compose.yml files to be read directly by Docker, without using Compose.
So the real question might be: what is the difference between docker compose and docker stack? Not a whole lot. Compose is actually a separate project, written in Python that uses the Docker API under the hood. Stack does much of the same things as Compose, but is integrated into Docker. Stack also wants pre-built images, while compose will handle those image builds for you, which makes compose very handy for development.
What you are dealing with might be a product of a time when these 2 tools were a lot more distinct. Docker Swarm is part of Docker, and it allows for easy scaling if needed (even if you don't need it now, it might be good down the road). On the other hand, Compose (in my opinion anyway) is much more useful for development situations where you are making frequent tweaks to your images, and rebuilding.
I know that Docker and Kubernetes aren’t direct competitors. Docker is the container platform and containers are coordinated and scheduled by Kubernetes, which is a tool.
What does it really mean and how can I deploy my app on Docker for Azure ?
Short answer:
Docker (and containers in general) solve the problem of packaging an application and its dependencies. This makes it easy to ship and run everywhere.
Kubernetes is one layer of abstraction above containers. It is a distributed system that controls/manages containers.
My advice: because the landscape is huge... start learning and putting the pieces of the puzzle together by following a course. Below I have added some information from the:
Introduction to Kubernetes, free online course from The Linux Foundation.
Why do we need Kubernetes (and other orchestrators) above containers?
In the quality assurance (QA) environments, we can get away with running containers on a single host to develop and test applications. However, when we go to production, we do not have the same liberty, as we need to ensure that our applications:
Are fault-tolerant
Can scale, and do this on-demand
Use resources optimally
Can discover other applications automatically, and communicate with each other
Are accessible from the external world
Can update/rollback without any downtime.
Container orchestrators are the tools which group hosts together to form a cluster, and help us fulfill the requirements mentioned above.
Nowadays, there are many container orchestrators available, such as:
Docker Swarm: Docker Swarm is a container orchestrator provided by Docker, Inc. It is part of Docker Engine.
Kubernetes: Kubernetes was started by Google, but now, it is a part of the Cloud Native Computing Foundation project.
Mesos Marathon: Marathon is one of the frameworks to run containers at scale on Apache Mesos.
Amazon ECS: Amazon EC2 Container Service (ECS) is a hosted service provided by AWS to run Docker containers at scale on its infrastructrue.
Hashicorp Nomad: Nomad is the container orchestrator provided by HashiCorp.
Kubernetes is built on Docker technology. It is an orchestration tool for Docker container whereas Docker is a technology to create and deploy containers.
Docker, starting with a platform-as-a-service (PaaS) provider named dotCloud.
All in all, Kubernetes is related to the Docker container, allowing you to implement application portability and extensibility in container orchestration.
DOCKER
Easy and fast to install and configure
Functionality is provided and limited by the Docker API
Quick container deployment and scaling even in very large clusters
Automated internal load balancing through any node in the cluster
Simple shared local volumes
Kubernetes
Require some work to get up and running
Client, API and YAML definitions are unique to Kubernetes
Provides strong guarantees to cluster states at the expense of speed
To Enable load balancing requires manual service configuration
Volumes shared within pods
This is just a basic idea which at least explains the difference.If you want to go in depth see my posts
http://www.thecreativedev.com/an-introduction-to-kubernetes/
http://www.thecreativedev.com/learn-docker-works/
Docker and Kubernetes are complementary. Docker provides an open standard for packaging and distributing containerized applications, while Kubernetes provides for the orchestration and management of distributed, containerized applications created with Docker. In other words, Kubernetes provides the infrastructure needed to deploy and run applications built with Docker.
To make a scale-able architecture with docker containers is a very attractive solutions to deal with scale-ability issue. We can auto scale docker containers in Amazon Elastic Beanstalk environment or in a vendor specific pass environments.
What is the best way to make your own scale-able docker architecture on commodity cloud servers such as Digital Ocean or Rackspace that will auto provisions containers based on loads.
The most known solution for managing scaling a docker-based infrastructure are:
docker swarm
Kubernetes
for CoreOS, Fleet
Apache Mesos
This article mentions:
In terms of scale, only Mesos has been proven to support large-scale systems of hundreds or thousands of nodes. However, when looking at small clusters of, say, less than a dozen nodes, Mesos may be an overly complex solution.
As mentioned here:
Almost everything we can do with Docker we can do with Swarm as well only on a much larger scale. There’s nothing new to do, no configurations to be duplicated and nothing new to learn.
So start with Docker Swarm first, and if particular needs arise, look for the other solutions.
See:
"Deploy and Manage Any Cluster Manager with Docker Swarm"
"Using Machine to provision Docker Swarm clusters"