docker-machine create –driver virtualbox –virtualbox-cpu-count "2" –virtualbox-memory "2048" –virtualbox-disk-size "20000" swarm-node-1
docker-machine env swarm-node-1 // tcp: //192.168.99.100: 2376
eval $ (docker-machine env swarm-node-1)
We launch the second node:
docker-machine create –driver virtualbox –virtualbox-cpu-count "2" –virtualbox-memory "2048" –virtualbox-disk-size "20000" swarm-node-2
docker-machine env swarm-node-2
eval $ (docker-machine env swarm-node-2)
We launch the third node:
docker-machine create –driver virtualbox –virtualbox-cpu-count "2" –virtualbox-memory "2048" –virtualbox-disk-size "20000" swarm-node-3
eval $ (docker-machine env swarm-node-3)
Let's connect to the first node, initialize the distributed storage in it and pass it the address of the manager (leader) node:
docker-machine ssh swarm-node-1
docker swarm init –advertise-addr 192.168.99.100:2377
docker node ls // will display the current
docker swarm join-token worker
If tokens are forgotten, they can be obtained by executing the commands docker swarm join-token manager and docker swarm join-token worker in a node with a distributed storage .
To create a cluster, it is necessary to register (join) all its future nodes with the Docker swarm join –token … 192.168.99.100:2377 command , a token is used for authentication, to discover them, they must be on the same subnet. You can view all servers with the docker node info command
The docker swarm init command will create a cluster leader, while alone, but in the response received, the command necessary to connect other nodes to this cluster will be given, important information in which is a token, for example, docker swarm join –token … 192.168 .99.100: 2377 . Connect to the remaining nodes via SSH using the docker-machine SSH name_node command and execute it.
For the interaction of containers, the bridge network is used, which is a switch. But for several replicas to work, a subnet is needed, since all replicas will have the same ports, and proxying is done by ip using a distributed storage, and it does not matter whether they are physically located on the same server or different. It should be noted right away that balancing is carried out according to the roundrobin rule, that is, one by one to each replica. It is important to create an overlay network to create DNS on top of it and be able to refer to replicas by name. Let's create a subnet:
docker network create –driver overlay –subnet 10.10.1.0/24 –opt encrypted services
Now we need to fill the cluster with containers. To do this, we create not a container, but a service, which is a template for creating containers on different nodes. The number of replicas to be created is specified during creation in the –replicas key , and the distribution is random over the nodes, but as uniform as possible. In addition to replicas, the service has a load balancer, the ports from which (input ports for all replicas) are proxied are specified in the -p switch , and Server Discovery (discovery of working replicas, determining their IP addresses, restarting) replicas are performed by the balancer independently.
docker service create -p 80:80 –name busybox –replicas 2 –network services busybox sleep 3000
Let's check the status of the docker service ls service , the status and uniformity of the distribution of the docker service ps busybox container replicas and its work wget -O- 10.10.1.2 . Service is a higher-level abstraction, which includes the container and organizing its update (by no means only), that is, to update the container parameters, you do not need to delete and create it, but simply update the service, and the service will first create a new one with the updated configuration, and only after it starts will delete the old one.
Docker Swarm has its own load balancer Ingress load balacing, which balances the load between replicas on the port declared when creating the service, in our case it is port 80. The entry point can be any server with this port, but the response will be received from the server to which the request was forwarded by the balancer.
We can also save data to the host machine, as in a regular container, there are two options for this:
docker service create –mount type = bind, src = …, dst = .... name = .... ..... #
docker service create –mount type = volume, src = …, dst = .... name = .... ..... # to host
The application is deployed via Docker-compose running on nodes (replicas). When updating the Docker-compose configuration, you need to update the Docker stack, and the cluster will be consistently updated: one replica will be deleted and a new one will be created in its place in accordance with the new config, then the next one. If an error occurs, a rollback will be made to the previous configuration. Well, let's get started:
docker stack deploy -c docker-compose.yml test_stack
docker service update –label-add foo = bar Nginx docker service update –label-rm foo Nginx docker service update –publish-rm 80 Nginx docker node update –availability = drain swarm-node-3 swarm-node-3
Docker swarm
$ sudo docker pull swarm
$ sudo docker run –rm swarm create
docker secrete create test_secret docker service create –secret test_secret cat / run / secrets / test_secret health check: hello-check-cobbalt example pipeline: trevisCI -> Jenkins -> config -> https://www.youtube.com/watch? v = UgUuF_qZmWc https://www.youtube.com/watch?v=6uVgR9WPjYM
Docker company-wide
Let's take a company-wide view: we have containers and we have servers. It doesn't matter if these are two virtual machines and several containers or hundreds of servers and thousands of containers, the problem is to distribute containers on the servers, you need a system administrator and time, if there is little time and a lot of containers, you need a lot of system administrators, otherwise they will be suboptimally distributed. that is, the server (virtual machine) is working, but not at full capacity and the resources are being sold. In this situation, container orchestration systems are designed to optimize distribution and save human resources.
Consider evolution:
* The developer creates the necessary containers by hand.
* The developer creates the necessary containers using previously prepared scripts.
* The system administrator, using any configuration and deployment management system, such as Chef, Pupel, Ansible, Salt, sets the topology of the system. The topology indicates which container is located in which place.
* Orchestration (schedulers) – semi-automatic distribution, maintenance of the state and reaction to system changes. For example: Google Kubernetes, Apache Mesos, Hashicorp Nomad, Docker Swarm mode, and YARN, which we'll cover. New ones also appear: Flocker (https://github.com/ClusterHQ/Flocker/), Helios (https://github.com/spotify/helios/).
There is a native Docker-swarm solution. Of the adult systems, Kubernetes (Kubernetes) and Mesos showed the most popularity, while the former is a universal and completely ready-to-use system, and the latter is a complex of various projects combined into a single package and allowing you to replace or change their components. There is also a huge number of less popular solutions that are not promoted by such giants as Google, Twitter and others: Nomad, Scheduling, Scalling, Upgrades, Service Descovery, but we will not consider them. Here we will consider the most ready-made solution – Kubernetes, which has gained great popularity for its low entry threshold, support and sufficient flexibility in most cases, pushing Mesos into the niche of customizable solutions when customization and development is economically justified.
Kubernetes has several ready-made configurations:
* MiniKube – a cluster of one local machine, designed to overcome the threshold of entry and experiments;
* kubeadm;
* kops;
* Kubernetes-Ansible;
* microKubernetes;
* OKD;
* MicroK8s.
To start the cluster yourself, you can use
KubeSai – Free Kubernetes
The smallest structural unit is called POD, which corresponds to the YML file in Docker-compose. The process of creating a POD, like other entities, is done declaratively: by writing or changing a configuration YML file and applying it to a cluster. And so, let's create a POD:
# test_pod.yml
# kybectl create -f test_pod.yaml
containers:
– name: test
image: debian
To run multiple replicas:
# test_replica_controller.yml
# kybectl create -f test_replica_controller.yml
apiVersion: v1
kind: ReplicationController
metadata:
name: Nginx
spec:
replicas: 3
selector:
app: Nginx // label by which the replica determines the presence of running containers
template:
containers:
– name: test
image: debian
For balancing, a type of service (logical entity) is used – LoadBalancer, in addition to which there is also ClasterIP and Node Port:
appVersion: v1
kind: Service
metadata:
name: test_service
apec:
type: LoadBalanser
ports:
– port: 80
– targetPort: 80
– protocol: TCP
– name: http
selector:
app: WEB
Overlay network plugins (created and configured automatically): Contig, Flannel, GCE networking, Linux bridging, Calico, Kube-DNS, SkyDNS. #configmap apiVersion: v1 kind: ConfigMap metadata: name: config_name data:
Similar to secrets in Docker-swarm, there is a secret for Kubernetes, an example of which can be NGINX settings:
#secrets
apiVersion: v1
kind: Secrets
metadata: name: test_secret
data:
password: ....
And to add a secret to POD, you need to specify it in the POD config:
....
valumes:
secret:
secretName: test_secret
…
Kubernetes has more flavors of Volumes:
* emptyDir;
* hostPatch;
* gcePersistentDisc – drive on Google Cloud;
* awsElasticBlockStore – A disk on Amazon AWS.
volumeMounts:
– name: app
nountPath: ""
volumes:
– name: app
hostPatch:
....
Feature for UI: Dashbord UI
Additionally available:
* Main metrics – collection of metrics;
* Logs collect – collecting logs;
* Scheduled JOBs;
* Autentification;
* Federation – distribution by data centers;
* Helm is a package manager similar to Docker Hub.
https://www.youtube.com/watch?v=FvlwBWvI-Zg
Docker commands
Docker is a more modern counterpart to RKT containers.
In Linux, when a process terminates with PID = 1, then NameSpace is also buried, which leads to the shutdown of the OS, in the case of a container, similarly, since it is a special case of the OS. The delimitation of processes in itself does not provide additional overhead, as well as monitoring and limiting resources for processes, because systemd provides the same configuration options in the host OS. Network virtualization occurs completely: both localhost and bridge, which allows you to create bridges from several containers to one localhost and thereby make it a single one for them, which is actively used in POD Kubernetes.
Run a temporary container interactively -it . To enter, you need to press Ctrl + D, which will send a signal to shutdown, after which it will be removed by –rm to avoid clogging the system with stopped modern containers. If the image is created in such a way that the application is launched in the shell in the container, which is wrong, then the signal will be poisoned to the application, and the container will continue to work with the shell, in which case, to exit in a separate terminal, you will need to kill it by its name –name name_container. For instance,:
Docker run –rm -it –name name_container ubuntu BASH
In the beginning, the Docker CLI had a simple set of commands to manage the lifecycle of containers. Among them:
* Docker run to run the container;
* Docker ps to view running containers;
* Docker rm to remove a container;
* Docker build to create your own image;
* Docker images to view existing containers;
* Docker rmi to remove the image.
But with the growing popularity, the teams became more and more and it was decided to group them into groups, so instead of the simple "Docker run", the "Docker container" command appeared, which has 25 commands in the 19 version of Docker. These are cleanup, and stop and restore, and logs and various kinds of container connections. The same fate befell the work with images. But, the old commands have remained so far due to compatibility and convenience, because in most cases a basic set is required. Let's stop at it:
Starting a container:
docker run -d –name name_container ubuntu bash
Remove a running container:
docker rm -f name_container
Output of all containers:
docker ps -a
Output of running containers:
docker ps
Output of containers with consumed resources:
docker stats
Displaying processes in a container:
docker top {name_container}
Connect to the container through the sh shell (there is no BASH in alpine containers):
docker exec -it sh
Cleaning the system from unused images:
docker image prune
Remove hanging images:
docker rmi $ (docker images -f "dangling = true" -q)
Show image:
docker images
Create image in dir folder with Dockerfile:
docker build -t docker_user / name_image dir
Delete image:
docker rmi docker_user / name_image dir
Connect to Docker hub:
docker login
Submit the latest revision (the tag is added and shifted automatically, if not specified otherwise) the image on the Docker hub:
docker push ocker_user / name_image dir: latest
For a broader list at https://niqdev.github.io/devops/docker/.
Building a Docker Machine can be described in the following steps:
Creating a VirtualBox virtual machine
docker-machine create name_virtual_system
Creating a generic virtual machine
docker-machine create -d generic name_virtual_system
List of virtual machines:
docker-machine ls
Stop the virtual machine:
docker-machine stop name_virtual_system
Start a stopped virtual machine:
docker-machine start name_virtual_system
Delete virtual machine:
docker-machine rm name_virtual_system
Connect to virtual machine:
eval "$ (docker-machine env name_virtual_system)"
Disconnect Docker from VM:
eval $ (docker-machine env -u)
Login via SSH:
docker-machine ssh name_virtual_system
Quit the virtual machine:
exit
Run the sleep 10 command in the virtual machine:
docker-machine ssh name_virtual_system 'sleep 10'
Running commands in BASH environment:
docker-machine ssh dev 'bash -c "sleep 10 && echo 1"'
Copy the dir folder to the virtual machine:
docker-machine scp -r / dir name_virtual_system: / dir
Make a request to the containers of the virtual machine:
curl $ (docker-machine ip name_virtual_system): 9000
Forward port 9005 of host machine to 9005 virtual machine
docker-machine ssh name_virtual_system -f -N -L 9005: 0.0.0.0: 9007
Master initialization:
docker swarm init
Running multiple containers with the same EXPOSE:
essh @ kubernetes-master: ~ / mongo-rs $ docker run –name redis -p 6379 -d redis
f3916da35b6ba5cd393c21d5305002b78c32b089a6cc01e3e2425930c9310cba
essh @ kubernetes-master: ~ / mongo-rs $ docker ps | grep redis
f3916da35b6b redis "docker-entrypoint.s…" 8 seconds ago Up 6 seconds 0.0.0.0:32769->6379/tcp redis
essh @ kubernetes-master: ~ / mongo-rs $ docker port reids
Error: No such container: reids
essh @ kubernetes-master: ~ / mongo-rs $ docker port redis
6379 / tcp -> 0.0.0.0:32769
essh @ kubernetes-master: ~ / mongo-rs $ docker port redis 6379
0.0.0.0:32769
Build is the first solution to copy all files and install. As a result, when any file changes, all packages will be reinstalled:
COPY ./ / src / app
WORKDIR / src / app
RUN NPM install
Let's use caching and split the static files and the installation: