Update: Docker just released support for Kubernetes as scheduler, which changes the situation and makes Kubernetes just an alternative scheduler to Docker Swarm.
TL;DR: DON'T DO IT. Engineers always try to create these dog-pigs. Every unnecessary technology you bring will bring another whole set of faults. If you can pick one, then pick one and be happy ...
Probably not the answer that you're looking for, but an answer nonetheless :)
Learning about docker and its deployment methods could actually be included in the business requirements by making it part of the project or team development environment, just like the code language(s), version control system, compilers, test infrastructure, etc - to work in that ...
I'll give you my perspective. Developers should care about docker as there are other developers who are willing to use docker and have already built an expertise in it. They are willing to take up the roles of a DevOps engineer along with being a developer. So the Ops part of DevOps is what they are now building expertise on.
These days, you'll find more ...
It is not about Docker or any other containerisation technologies out there.
Containers like Docker, rkt, etc. are just way of delivering your application in similar fashion to static binary. You are building your deployment that it contains everything it need inside and end user doesn't need anything more than runtime.
These solutions are similar to fat ...
If you are only running a single container or two containers together you are correct in that an orchestrator may be unnecessary and add unneeded complexity. However, these tools do solve several issues when you running several containers together (especially in production).
What are the common problems with containers that must be solved by these ...
If you are running your production in docker container it's crucial that those container are being made by the same developers that have build the app running on them.
Who else is better place to know what external dependency are needed and so on ... ?
Also pipeline can fail at any step during a CD, particularly when it's the docker image build step, ...
Here are for example some arguments from a blog post published back 2014 and titled in way quite matching your answer:
Much more flexible injection of new technologies into the environment
there is still a massive pain point between committing the final tested code and then getting it running on the final production servers. Docker vastly simplifies ...
why not posting this as 5 different questions?
Google for "left shift" in DevOps context.
Consider DevOps team patterns http://web.devopstopologies.com/
"While DevOps raise problems and dispatch them to Dev to solve, the SRE approach is to find problems and solve some of them themselves." https://devops.com/sre-vs-devops-false-distinction/
welcome to DevOps SE, @bgarcial!
Well I think there are the following options depending on the use case:
Docker Container links are a according to the vendor site a legacy feature and you shouldn't use it
Docker compose should work well but you can't scale horizontally: the stack is runnable only one a single machine
With Docker Swarm using mostly same YML ...
We do not support depends_on, and neither does Docker in Swarm mode.
It is not a real solution to the problem anyway and leaves you with
unhandled pointy-edge cases when failures occur and containers are
being replaced. Your services should know how to either wait for their
Is there a reason why you are trying to monitor it from the outside? Can an autoscaling group with a load balancer be a solution. If yes, then provisioning these resources, having the ability to track & update configuration is something that will be possible using a tool like terraform(multi-cloud support) or cloudformation(cloud-specific).
Ansible might ...
Welcome to the wonderful world of container orchestrators.
Consider microservices for a moment. Each service should be independently deployed and independently scaled across a cluster of VMs. Where does basic Docker and Docker Compose fit in? They don’t compete with distributed system orchestrators like Openshift Kubernetes, CloudFoundry or Docker Swarm.
Take a look at OpenShift container platform (https://www.openshift.com/products/container-platform/). They seem to provide on-premise options. You might want to start with OpenShift Origin - the community edition (https://github.com/openshift/origin) to test for free if it fits your plan.
Edit: The deploy script that is described in this answer is very much looks like Helmfile and we are now in the process of upgrading to Helmfile so that we can retire our scripts that run multiple Helm releases as that’s that Helmfile does well.
This is a bit of an alternative and indirect answer. Use infrastructure-as-code best practices to avoid ...
Docker gets lots of press and blog mentions which leads to developers getting interested in using it. For some people it is the interest in playing with a new technology or understanding how things work. For others it is a desire to add keywords to their resume. Either way, the more developers know about how things work and how they get deployed the less ...
What would be the best way to share ports among the containers?
You don't really "share" ports between containers. Instead, you want to create network and attach each container to that network. Each container gets a network alias (essentially a hostname) that you can use to hit the service.
$ docker network create foo
$ docker run --network=foo --...
You can include the arguments in the deployment yaml. The official docs include examples and further customization.
args: ["me", "yes", "https://my.url"]
A container runtime is the part of your container environment in charge of the creation and basic features of your containers. The obvious one is Docker, but you can also find Containerd, CRI-O and other as runtime for your containers.
An orchestrator, by contrast, will not exactly create your container (ie, an orchestrator is not the technology used to ...
TL;DR; Terraform does allow you to get a lot of what you want done.
Also, you might benefit from a more managed solution like AWS Fargate (which you also declare with Terraform).
Whenever I use search keywords such as "orchestration" or "server clusters" or "iaas" I'll always end up in hundreds of results that are going to talk ...
Based on my experience I'd suggest following scenario:
First you should make your apps deployment process similar for all environments, so same tool and set of files will be responsible for this part. And only difference should goes to parameters.
And second it's always a good practice to have kubernetes cluster per stage. Very common situation when your ...
I think it depends on the context.
I feel your pain with regard to needing to tinker and tweak a MySQL/MariaDB instance. It's not extremely difficult to get an instance up and running and THEN populate the DB from, say, a mysqldump by attaching volumes to the MySQL instance either using a Dockerfile for the instance or by "manually" bash-ing into ...
The answer is in the warning you get:
[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'
When you use hosts: all in your playbook, localhost is not matched.
If you want to run the playbook on localhost, you can do one of the following:
Change your playbook to hosts: localhost.
I spent a long time on this problem and made 2 custom solutions as nothing out of the box exists.
Both steps require you to either use both the experimental and the extra plugin API or to have access to the remote database.
At that point, basically either:
Make a GUI plugin on a separate page that hits the APIs and shows all tasks (list exec dates, list ...
According to the README of the deis/workflow project on GitHub, it is no longer maintained since March 1, 2018.
However, the README indicates that there is a fork, called Hephy Workflow. At the time of writing, this is the first time I heard about Deis and Hephy and I have not worked with these solutions.
Alternatives to these products are OpenShift, ...
I would say that Istio is the de facto standard for Service Mesh. It is launched by both Google and IBM.
Welcome to the service mesh era: Introducing a new Istio blog post series
IBM, Google Cloud and the open community launch Istio 1.0 to bring microservices to the enterprise
I don't think "Managed Kubernetes" is reserved for AWS (EKS), there is Microsoft's Azure Kubernetes Service (AKS) and Google Kubernetes Engine (GKE) also, besides Red Hat's OpenShift. Those work as SaaS (or KaaS if you will).
OpenShift has an on-premise version you can try called MiniShift in the OpenShift.org site, while there are other alternatives as ...
Your impression is false, linux containers (LXC) exists since 2008, mesos and docker have started later. All three makes use of cgroups available since kernel 2.6.28.
For your overall question, mesosphere have a blog post about it.
But mainly you're looking at it from the wrong point of view, choosing the underlying orchestration system should not be ...
You should take a look at BOSH. Its the tool that is used by CloudFoundry, its services and a distro of Kubernetes called Kubo for installation, management and "Day 2" operations.
It's basically a declarative, cloud-agnostic orchestration tool that features rolling updates, canary deployments, scaling, monitoring and self healing. It can monitor VMs as ...