|
|
| (78 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| | + | [[Docker basic]] |
| | | | |
| − | =Manage Virtual Hosts with docker-machine=
| + | [[Docker Compose]] |
| − | <br>
| |
| − | ==Introduction==
| |
| − | | |
| − | Docker Machine is a tool that lets you install Docker Engine on virtual hosts, and manage the hosts with docker-machine commands. You can use Machine to create Docker hosts on your local Mac or Windows box, on your company network, in your data center, or on cloud providers like Azure, AWS, or Digital Ocean.
| |
| − | | |
| − | Using docker-machine commands, you can start, inspect, stop, and restart a managed host, upgrade the Docker client and daemon, and configure a Docker client to talk to your host.
| |
| − | :[[File:ClipCapIt-180622-224748.PNG]]
| |
| − | | |
| − | When people say “Docker” they typically mean Docker Engine, the client-server application made up of the Docker daemon, a REST API that specifies interfaces for interacting with the daemon, and a command line interface (CLI) client that talks to the daemon (through the REST API wrapper). Docker Engine accepts docker commands from the CLI, such as docker run <image>, docker ps to list running containers, docker image ls to list images, and so on.
| |
| − | | |
| − | '''Docker Machine''' is a tool for provisioning and managing your Dockerized hosts (hosts with Docker Engine on them). Typically, you install Docker Machine on your local system. Docker Machine has its own command line client docker-machine and the Docker Engine client, docker. You can use Machine to install Docker Engine on one or more virtual systems. These virtual systems can be local (as when you use Machine to install and run Docker Engine in VirtualBox on Mac or Windows) or remote (as when you use Machine to provision Dockerized hosts on cloud providers). The Dockerized hosts themselves can be thought of, and are sometimes referred to as, managed “machines”.
| |
| − | | |
| − | Source: https://docs.docker.com/machine/overview/<br>
| |
| − | | |
| − | | |
| − | ==Hypervisor drivers==
| |
| − | <br>
| |
| − | ===What is a driver===
| |
| − | Machine can be created with the '''docker-machine create''' command.
| |
| − | Most simple usage:
| |
| − | <pre>
| |
| − | docker-machine create -d <hybervisor driver name> <driver options> <machine name>
| |
| − | </pre>
| |
| − | | |
| − | The default value of the driver parameter is "virtualbox".
| |
| − | | |
| − | '''docker-machine''' can create and manage virtual hosts on the local machine and on remote clouds. Always the chosen driver determines where and how the virtual machine will be created. The guest operating system that is being installed on the new machine is also determined by the hypervisor driver. E.g. with the "virtualbox" driver you can create machines locally using the boot2docker as the guest OS.
| |
| − | | |
| − | The driver also determines the virtual network types and interfaces types that are created inside the virtual machine. E.g. the KVM driver creates two virtual networks (bridges), one host-global and one host-private network.
| |
| − | | |
| − | In the '''docker-machine create''' command, the available driver options are also determined by the driver. You always has to check the available options at the vandor of driver. For cloud drivers typical options are the remote url, the login name and the password. Some driver allows to change the guest OS, the CPU number or the default memory.
| |
| − | | |
| − | Here is a complete list of the currently available drivers: https://github.com/docker/docker.github.io/blob/master/machine/AVAILABLE_DRIVER_PLUGINS.md
| |
| − | <br>
| |
| − | <br>
| |
| − | ===KVM driver===
| |
| − | | |
| − | KVM driver home page: https://github.com/dhiltgen/docker-machine-kvm
| |
| − | | |
| − | Minimum Parameters:
| |
| − | * --driver kvm
| |
| − | * --kvm-network: The name of the kvm virtual (public) network that we would like to use. If this is not set, the new machine will be connected to the '''"default"''' KVM virtual network.
| |
| − | | |
| − | '''Images''':<br>
| |
| − | By default docker-machine-kvm uses a boot2docker.iso as guest os for the kvm hypervisior. It's also possible to use every guest os image that is derived from boot2docker.iso as well. For using another image use the --kvm-boot2docker-url parameter.
| |
| − | | |
| − | '''Dual Network''':<br>
| |
| − | * '''eth1''' - A host private network called docker-machines is automatically created to ensure we always have connectivity to the VMs. The docker-machine ip command will always return this IP address which is only accessible from your local system.
| |
| − | * '''eth0''' - You can specify any libvirt named network. If you don't specify one, the "default" named network will be used.
| |
| − | If you have exotic networking topolgies (openvswitch, etc.), you can use virsh edit mymachinename after creation, modify the first network definition by hand, then reboot the VM for the changes to take effect.
| |
| − | Typically this would be your "public" network accessible from external systems
| |
| − | To retrieve the IP address of this network, you can run a command like the following:
| |
| − | docker-machine ssh mymachinename "ip -one -4 addr show dev eth0|cut -f7 -d' '"
| |
| − | | |
| − | Driver Parameters:<br>
| |
| − | *--kvm-cpu-count Sets the used CPU Cores for the KVM Machine. Defaults to 1 .
| |
| − | *--kvm-disk-size Sets the kvm machine Disk size in MB. Defaults to 20000 .
| |
| − | *--kvm-memory Sets the Memory of the kvm machine in MB. Defaults to 1024.
| |
| − | *--kvm-network Sets the Network of the kvm machinee which it should connect to. Defaults to default.
| |
| − | *--kvm-boot2docker-url Sets the url from which host the image is loaded. By default it's not set.
| |
| − | *--kvm-cache-mode Sets the caching mode of the kvm machine. Defaults to default.
| |
| − | *--kvm-io-mode-url Sets the disk io mode of the kvm machine. Defaults to threads.
| |
| − | | |
| − | <br>
| |
| − | ==Install softwares==
| |
| − | | |
| − | First we have to install the docker-machine app itself:
| |
| − | <pre>
| |
| − | base=https://github.com/docker/machine/releases/download/v0.14.0 &&
| |
| − | curl -L $base/docker-machine-$(uname -s)-$(uname -m) >/tmp/docker-machine &&
| |
| − | sudo install /tmp/docker-machine /usr/local/bin/docker-machine
| |
| − | </pre>
| |
| − | | |
| − | | |
| − | Secondly we have to install the hypervisor driver for the docker-machine to be able to create, manage Virtual Machines running on the hypervisor. As we are going to use the KVM hypervisor, we have to install the "docker-machine-driver-kvm" driver:
| |
| − | <pre>
| |
| − | # curl -Lo docker-machine-driver-kvm \
| |
| − | https://github.com/dhiltgen/docker-machine-kvm/releases/download/v0.7.0/docker-machine-driver-kvm \
| |
| − | && chmod +x docker-machine-driver-kvm \
| |
| − | && sudo mv docker-machine-driver-kvm /usr/local/bin
| |
| − | </pre>
| |
| − | | |
| − | We suppose that KVM and the libvirt is already installed on the system.
| |
| − | {{tip|If you want to use VirtualBox as your hypervisor, no extra steps are needed, as its docker-machine driver is included in the docker-machine app}}
| |
| − | | |
| − | | |
| − | Available 3rd party drivers: <br>
| |
| − | https://github.com/docker/docker.github.io/blob/master/machine/AVAILABLE_DRIVER_PLUGINS.md
| |
| − | <br>
| |
| − | <br>
| |
| − | | |
| − | ==Create machines with KVM==
| |
| − | | |
| − | ===Create the machine===
| |
| − | | |
| − | Before a new machine can be created with the docker-machine command, the proper KVM virtual network must be created.
| |
| − | | |
| − | See [[KVM#Add_new_networ|How to create KVM networks]] for details.
| |
| − | | |
| − | <pre>
| |
| − | # docker-machine create -d kvm --kvm-network "docker-network" manager
| |
| − | | |
| − | Running pre-create checks...
| |
| − | Creating machine...
| |
| − | (manager) Copying /root/.docker/machine/cache/boot2docker.iso to /root/.docker/machine/machines/manager/boot2docker.iso...
| |
| − | Waiting for machine to be running, this may take a few minutes...
| |
| − | Detecting operating system of created instance...
| |
| − | Waiting for SSH to be available...
| |
| − | Detecting the provisioner...
| |
| − | Provisioning with boot2docker...
| |
| − | Copying certs to the local machine directory...
| |
| − | Copying certs to the remote machine...
| |
| − | Setting Docker configuration on the remote daemon...
| |
| − | Checking connection to Docker...
| |
| − | Docker is up and running!
| |
| − | To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env manager
| |
| − | </pre>
| |
| − | | |
| − | {{tip|The machine is created under '''/USER_HOME/.docker/machine/machines/<machine_name>''' directory
| |
| − | | |
| − | If the new VM was created with virtualbox driver, the VirtualBox graphical management interface must be started with the same user, that the VM was created with, and the VirtualBox will discover the new VM automatically}}
| |
| − | | |
| − | ===Check what was created===
| |
| − | <br>
| |
| − | ====Interfaces on the host====
| |
| − | <pre>
| |
| − | # ifconfig
| |
| − | eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
| |
| − | inet 192.168.0.105 netmask 255.255.255.0 broadcast 192.168.0.255
| |
| − | ....
| |
| − | virbr1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
| |
| − | inet 192.168.42.1 netmask 255.255.255.0 broadcast 192.168.42.255
| |
| − | ...
| |
| − | virbrDocker: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
| |
| − | inet 192.168.123.1 netmask 255.255.255.0 broadcast 192.168.123.255
| |
| − | inet6 2001:db8:ca2:2::1 prefixlen 64 scopeid 0x0<global>
| |
| − | ...
| |
| − | </pre>
| |
| − | On the host, upon the regular interfaces, we can see the two bridges for the two virtual networks:
| |
| − | * '''virbrDocker''': That is the virtual network that we created in libvirt. This is connected to the host network with NAT. We assigned these IP addresses, when we defined the network.
| |
| − | * '''virbr1''': That is the host-only virtual network that was created out-of-the-box. This one has no internet access.
| |
| − | <br>
| |
| − | | |
| − | ====Interface the new VM====
| |
| − | You can log in to the newly created VM with the '''docker-machine ssh <machine_name>''' command
| |
| − | On the newly created docker ready VM, four interfaces were created.
| |
| − | <pre>
| |
| − | # docker-machine ssh manager
| |
| − | ## .
| |
| − | ## ## ## ==
| |
| − | ## ## ## ## ## ===
| |
| − | /"""""""""""""""""\___/ ===
| |
| − | ~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ / ===- ~~~
| |
| − | \______ o __/
| |
| − | \ \ __/
| |
| − | \____\_______/
| |
| − | _ _ ____ _ _
| |
| − | | |__ ___ ___ | |_|___ \ __| | ___ ___| | _____ _ __
| |
| − | | '_ \ / _ \ / _ \| __| __) / _` |/ _ \ / __| |/ / _ \ '__|
| |
| − | | |_) | (_) | (_) | |_ / __/ (_| | (_) | (__| < __/ |
| |
| − | |_.__/ \___/ \___/ \__|_____\__,_|\___/ \___|_|\_\___|_|
| |
| − | Boot2Docker version 18.05.0-ce, build HEAD : b5d6989 - Thu May 10 16:35:28 UTC 2018
| |
| − | Docker version 18.05.0-ce, build f150324
| |
| − | </pre>
| |
| − | <br>
| |
| − | Check the interfaces of the new VM:
| |
| − | <pre>
| |
| − | docker@manager:~$ ifconfig
| |
| − | docker0 inet addr:172.17.0.1 Bcast:172.17.255.255 Mask:255.255.0.0
| |
| − | ...
| |
| − | eth0 inet addr:192.168.123.195 Bcast:192.168.123.255 Mask:255.255.255.0
| |
| − | ...
| |
| − | eth1 inet addr:192.168.42.118 Bcast:192.168.42.255 Mask:255.255.255.0
| |
| − | </pre>
| |
| − | * '''eth0''':192.168.123.195 - Interface to the new virtual network (docker-network) created by us. this network is connected to the host network,so it has public internet access as well.
| |
| − | * '''eth1''':192.168.42.118 - This connect to the dynamically created host-only virtual network. Just for VM-to-VM communication
| |
| − | * '''docker0''':172.17.0.1 - This VM is ment to host docker container, so the docker daemon was already installed and started on it. Form docker point of view, this VM is also a (docker) host, and therefore the docker daemon created the default virtual bridge, that the containers will be connected to unless it is specified implicitly otherwise during container creation.
| |
| − | <br>
| |
| − | Inspect the new VM with the '''docker-machine inspect''' command
| |
| − | <pre>
| |
| − | # docker-machine inspect manager
| |
| − | {
| |
| − | "ConfigVersion": 3,
| |
| − | "Driver": {
| |
| − | ....
| |
| − | "CPU": 1,
| |
| − | "Network": "docker-network",
| |
| − | "PrivateNetwork": "docker-machines",
| |
| − | "ISO": "/root/.docker/machine/machines/manager/boot2docker.iso",
| |
| − | "...
| |
| − | },
| |
| − | "DriverName": "kvm",
| |
| − | "HostOptions": {
| |
| − | ....
| |
| − | },
| |
| − | "SwarmOptions": {
| |
| − | "IsSwarm": false,
| |
| − | ...
| |
| − | },
| |
| − | "AuthOptions": {
| |
| − | ....
| |
| − | }
| |
| − | },
| |
| − | "Name": "manager"
| |
| − | }
| |
| − | </pre>
| |
| − | <br>
| |
| − | | |
| − | ====Routing table====
| |
| − | | |
| − | <pre>
| |
| − | All the packages that ment to go to the docker VMs are routed to the bridges
| |
| − | # route
| |
| − | Kernel IP routing table
| |
| − | Destination Gateway Genmask Flags Metric Ref Use Iface
| |
| − | ...
| |
| − | 192.168.42.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr1 <<<<this
| |
| − | 192.168.123.0 0.0.0.0 255.255.255.0 U 0 0 0 virbrDocker <<<this
| |
| − | </pre>
| |
| − | <br>
| |
| − | ====IPtables modifications====
| |
| − | :[[File:ClipCapIt-180623-010335.PNG|800px]]
| |
| − | <br>
| |
| − | Switches:
| |
| − | * -o, --out-interface name
| |
| − | * -i, --input-interface name
| |
| − | * -s, source IP address
| |
| − | * -d, destination IP address
| |
| − | * -p, Sets the IP protocol for the rule
| |
| − | * -j, jump to the given target/chain
| |
| − | <br>
| |
| − | DNS and DCHP packages from the Virtual Bridges are allowed to be sent to the host machine.
| |
| − | <pre>
| |
| − | -A INPUT -i virbr1 -p udp -m udp --dport 53 -j ACCEPT
| |
| − | -A INPUT -i virbr1 -p tcp -m tcp --dport 53 -j ACCEPT
| |
| − | -A INPUT -i virbr1 -p udp -m udp --dport 67 -j ACCEPT
| |
| − | -A INPUT -i virbr1 -p tcp -m tcp --dport 67 -j ACCEPT
| |
| − | -A INPUT -i virbrDocker -p udp -m udp --dport 53 -j ACCEPT
| |
| − | -A INPUT -i virbrDocker -p tcp -m tcp --dport 53 -j ACCEPT
| |
| − | -A INPUT -i virbrDocker -p udp -m udp --dport 67 -j ACCEPT
| |
| − | -A INPUT -i virbrDocker -p tcp -m tcp --dport 67 -j ACCEPT
| |
| − | </pre>
| |
| − | <br>
| |
| − | The host machine is allowed to send DHCP packages to the virtual bridges in order to configure them.
| |
| − | <pre>
| |
| − | -A OUTPUT -o virbr1 -p udp -m udp --dport 68 -j ACCEPT
| |
| − | -A OUTPUT -o virbrDocker -p udp -m udp --dport 68 -j ACCEPT
| |
| − | </pre>
| |
| − | <br>
| |
| − | The bridge '''virbrDocker''' can send packages anywhere (first line) and can receive packages back if the connections was previously established (second line)<br>
| |
| − | <pre>
| |
| − | -A FORWARD -d 192.168.123.0/24 -o virbrDocker -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
| |
| − | -A FORWARD -s 192.168.123.0/24 -i virbrDocker -j ACCEPT
| |
| − | </pre>
| |
| − | <br>
| |
| − | The bridges can send packages to themselves, otherwise everything is rejected that was sent to or form the bridges
| |
| − | <pre>
| |
| − | -A FORWARD -i virbrDocker -o virbrDocker -j ACCEPT
| |
| − | -A FORWARD -i virbr1 -o virbr1 -j ACCEPT
| |
| | | | |
| − | #If not accepted above, we reject everything from the two bridges
| + | [[Docker Machine]] |
| − | -A FORWARD -o virbrDocker -j REJECT --reject-with icmp-port-unreachable
| |
| − | -A FORWARD -i virbrDocker -j REJECT --reject-with icmp-port-unreachable
| |
| − | -A FORWARD -o virbr1 -j REJECT --reject-with icmp-port-unreachable
| |
| − | -A FORWARD -i virbr1 -j REJECT --reject-with icmp-port-unreachable
| |
| − | </pre>
| |
| | | | |
| | + | [[Docker Swarm Classic]] |
| | | | |
| − | The bridge '''virbrDocker''' can send packages to the outside world. (MASQUERADE is a special SNAT target, where the destination IP doesn't have to be specified. SNAT replaces the source IP address of the package with the public IP address of our system)
| + | [[Docker Swarm Mode]] |
| − | Last two lines: The bridge can't send anything to the multicast and to the broadcast addresses.
| |
| − | <pre>
| |
| − | -A POSTROUTING -s 192.168.123.0/24 ! -d 192.168.123.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
| |
| − | -A POSTROUTING -s 192.168.123.0/24 ! -d 192.168.123.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
| |
| − | -A POSTROUTING -s 192.168.123.0/24 ! -d 192.168.123.0/24 -j MASQUERADE
| |
| − | -A POSTROUTING -s 192.168.123.0/24 -d 224.0.0.0/24 -j RETURN
| |
| − | -A POSTROUTING -s 192.168.123.0/24 -d 255.255.255.255/32 -j RETURN
| |
| − | </pre>
| |
| | | | |
| − | <br>
| + | [[Docker Swarm management]] |
| − | ==Manage machines==
| |
| − | <br>
| |
| | | | |
| − | ===List/Inspect===
| + | [[Docker volume orchestration]] |
| − | Whit the '''ls''' subcommand we can list all the docker-machine managed hosts.
| |
| − | <pre>
| |
| − | # docker-machine ls
| |
| − | NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
| |
| − | manager - kvm Running tcp://192.168.42.118:2376 v18.05.0-ce
| |
| − | </pre>
| |
| − | * NAME: name of the created machine
| |
| − | * ACTIVE: from the Docker client point of view, the active virtual host can be managed with the docker and with the docker-compose commands form the local host, as we would executed these commands on the remote virtual host. There can be always a single active machine that is marked with an asterisk '*' in the ls output.
| |
| − | * DRIVER:
| |
| − | * STATE:
| |
| − | * URL: The IP address of the virtual host.
| |
| − | * SWARM:
| |
| | | | |
| | + | [[Docker Swarm on AWS]] |
| | | | |
| − | With the '''inspect <machine name>''' subcommand we can get very detailed information about a specific machine:
| + | [[Stateful load-balancing in swarm]] |
| − | <pre>
| |
| − | # docker-machine inspect manager
| |
| − | {
| |
| − | "ConfigVersion": 3,
| |
| − | "Driver": {
| |
| − | "IPAddress": "",
| |
| − | "MachineName": "manager",
| |
| − | "SSHUser": "docker",
| |
| − | "SSHPort": 22,
| |
| − | "SSHKeyPath": "",
| |
| − | "StorePath": "/root/.docker/machine",
| |
| − | "SwarmMaster": false,
| |
| − | "SwarmHost": "tcp://0.0.0.0:3376",
| |
| − | "SwarmDiscovery": "",
| |
| − | "Memory": 1024,
| |
| − | "DiskSize": 20000,
| |
| − | "CPU": 1,
| |
| − | "Network": "docker-network",
| |
| − | "PrivateNetwork": "docker-machines",
| |
| − | "ISO": "/root/.docker/machine/machines/manager/boot2docker.iso",
| |
| − | ...
| |
| − | },
| |
| − | "DriverName": "kvm",
| |
| − | "HostOptions": {
| |
| − | ...
| |
| − | ...
| |
| − | "Name": "manager"
| |
| − | }
| |
| | | | |
| − | </pre>
| + | [[Centralized logging in swarm]] |
| | | | |
| − | <br>
| + | [[Metrics and Monitoring in swarm]] |
| | | | |
| − | ===Set Active machine===
| + | [[Auto-scaling swarm]] |
| − | With our local docker client we can connect to the docker daemon of any of the virtual hosts. That virtual host that we can managed locally is called "active" host. From Docker client point of view, the active virtual host can be managed with the '''docker''' and with the '''docker-compose''' commands form the local host, as we executed these commands on the (remote) virtual host.
| |
| − | We can make any docker-machine managed virtual host active with the ''''docker-machine env <machine name>'''' command. Docker gets connection information from
| |
| − | environment variables. With this command we can redirect our docker CLI.
| |
| − | Run this command in the host.
| |
| − | <pre>
| |
| − | # docker-machine env manager
| |
| − | export DOCKER_TLS_VERIFY="1"
| |
| − | export DOCKER_HOST="tcp://192.168.42.118:2376"
| |
| − | export DOCKER_CERT_PATH="/root/.docker/machine/machines/manager"
| |
| − | export DOCKER_MACHINE_NAME="manager"
| |
| − | # Run this command to configure your shell:
| |
| − | # eval $(docker-machine env manager)
| |
| − | </pre>
| |
| | | | |
| | + | [[Kafka with ELK on swarm]] |
| | | | |
| − | As the output of the env command suggests, you have to run the '''eval''' command in that shell that you want to use to managed the active virtual host.
| + | [[Java EE application with docker]]<br> |
| − | <pre> | + | Itt egy tipikus, produkciós docker architektúrát mutatunk be egy két lábas JBoss cluster-el, de swarm nélkül |
| − | # eval $(docker-machine env manager)
| |
| − | </pre>
| |
| | | | |
| | + | [[Java EE application with swarm]]<br> |
| | + | Egy lehetséges production grade swarm architektúra telepített Java EE alkalmazás kialakítását mutatjuk be. |
| | | | |
| − | Now, in the same shell, run the '''ls''' command again. The machine 'manager' will be marked with the asterisk in the ACTIVE column.
| |
| − | <pre>
| |
| − | # docker-machine ls
| |
| − | NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS
| |
| − | manager * kvm Running tcp://192.168.42.118:2376 v18.05.0-ce
| |
| − | </pre>
| |
| − |
| |
| − |
| |
| − | In the same shell on the host machine, create a docker container:
| |
| − | <pre>
| |
| − | # docker run -d -i -t --name container1 ubuntu /bin/bash
| |
| − | 9dfda56f7739831b0d19c8acd95748b1c93f6c6bb82d2aa87cfb10ecee0e4f28
| |
| − | </pre>
| |
| − |
| |
| − |
| |
| − | Now we will log on to the virtual host with the '''ssh <machine name>''' command.
| |
| − | <pre>
| |
| − | # docker-machine ssh manager
| |
| − | ## .
| |
| − | ## ## ## ==
| |
| − | ## ## ## ## ## ===
| |
| − | /"""""""""""""""""\___/ ===
| |
| − | ~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ / ===- ~~~
| |
| − | \______ o __/
| |
| − | \ \ __/
| |
| − | \____\_______/
| |
| − | _ _ ____ _ _
| |
| − | | |__ ___ ___ | |_|___ \ __| | ___ ___| | _____ _ __
| |
| − | | '_ \ / _ \ / _ \| __| __) / _` |/ _ \ / __| |/ / _ \ '__|
| |
| − | | |_) | (_) | (_) | |_ / __/ (_| | (_) | (__| < __/ |
| |
| − | |_.__/ \___/ \___/ \__|_____\__,_|\___/ \___|_|\_\___|_|
| |
| − | Boot2Docker version 18.05.0-ce, build HEAD : b5d6989 - Thu May 10 16:35:28 UTC 2018
| |
| − | Docker version 18.05.0-ce, build f150324
| |
| − | docker@manager:~$
| |
| − | </pre>
| |
| − |
| |
| − |
| |
| − | List the available docker containers. We should see there the newly created '''container1'''. The '''docker run''' command was executed in the host, bat was run in the remote, virtual host.
| |
| − | <pre>
| |
| − | docker@manager:~$ docker ps
| |
| − | CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
| |
| − | 9dfda56f7739 ubuntu "/bin/bash" 5 minutes ago Up 5 minutes container2
| |
| − | </pre>
| |
| − |
| |
| − | Running the '''docker ps''' command on the host, should give the same result.
| |
| | | | |
| | <br> | | <br> |
| − | | + | =Docker on Fedora 31= |
| − | ===Unset active machine===
| + | https://www.reddit.com/r/linuxquestions/comments/dn2psl/upgraded_to_fedora_31_docker_will_not_work/<br> |
| − | | + | https://fedoraproject.org/wiki/Changes/CGroupsV2<br |
| − | The active machine can be unset with the "'''--unset'''" switch. Once the active docker machine was unset, the docker client will manage the local docker daemon again.
| + | A Fedora31-ben bevezették a CGroupsV2-t amit a docker még nem követett le, ezért a docker a CGroupsV2-vel nem fog működni, ki kell kapcsolni. |
| − | <pre> | |
| − | # docker-machine env --unset
| |
| − | unset DOCKER_TLS_VERIFY
| |
| − | unset DOCKER_HOST
| |
| − | unset DOCKER_CERT_PATH
| |
| − | unset DOCKER_MACHINE_NAME
| |
| − | # Run this command to configure your shell:
| |
| − | # eval $(docker-machine env --unset)
| |
| − | </pre>
| |
| | | | |
| | | | |
| − | As the output suggest, we have to run the eval command again with the '''--unset''' switch to clear the shell. Alternatively you can just start a new shell.
| + | 1- |
| − | <pre>
| |
| − | # eval $(docker-machine env --unset)
| |
| − | </pre>
| |
| | | | |
| − | | + | vim /etc/default/grub |
| − | Now lets run the '''ps''' command again. As the docker client now connected to the local docker daemon, we shouldn't see '''container1''' anymore in the list.
| + | 2- Add Line below in GRUB_CMDLINE_LINUX systemd.unified_cgroup_hierarchy=0 |
| | <pre> | | <pre> |
| − | # docker ps
| + | GRUB_TIMEOUT=5 |
| − | CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
| + | GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" |
| − | 66e9cfbbc947 busybox "sh" 30 hours ago Up 4 minutes critcon
| + | GRUB_DEFAULT=saved |
| | + | GRUB_DISABLE_SUBMENU=true |
| | + | GRUB_TERMINAL_OUTPUT="console" |
| | + | GRUB_CMDLINE_LINUX="resume=/dev/mapper/fedora_localhost--live-swap rd.lvm.lv=fedora_localhost-live/root rd.luks.uuid=luks-42aca868-45a4-438e-8801-bb23145d978d rd.lvm.lv=fedora_localhost-live/swap rhgb quiet systemd.unified_cgroup_hierarchy=0" |
| | + | GRUB_DISABLE_RECOVERY="true" |
| | + | GRUB_ENABLE_BLSCFG=true |
| | </pre> | | </pre> |
| | | | |
| − | <br>
| + | 3- Then : |
| − | <br>
| |
| − | <br>
| |
| − | =Services=
| |
| − | | |
| − | ==Introduction==
| |
| − | In a distributed application, different pieces of the app are called “services.” Services are really just “containers in production.” A service only runs '''one''' '''image''', but it codifies the way that image runs—what ports it should use, '''how many replicas''' of the container should run so the service has the capacity it needs, and so on. Scaling a service changes the number of container instances running that piece of software, assigning more computing resources to the service in the process.
| |
| | | | |
| − | Luckily it’s very easy to define, run, and scale services with the Docker platform -- just write a docker-compose.yml file.
| + | # grub2-mkconfig |
| | | | |
| − | Source: https://docs.docker.com/get-started/part3/#prerequisites
| + | 4- Restart your PC |
| | | | |
| − | ==YAMEL==
| |
| − | YAML /'jæm.ḷ/ is a human-readable data serialization language. It is commonly used for configuration files, but could be used in many applications where data is being stored (e.g. debugging output) or transmitted (e.g. document headers). YAML targets many of the same communications applications as XML but has a minimal syntax which intentionally breaks compatibility with SGML [1]. It uses both Python-style indentation to indicate nesting, and a more compact format that uses [] for lists and {} for maps making YAML 1.2 a superset of JSON.
| |
| − | Custom data types are allowed, but YAML natively encodes scalars (such as strings, integers, and floats), lists, and associative arrays (also known as hashes, maps, or dictionaries).
| |
| | | | |
| | | | |
| − | =Docker Composition=
| |
| | | | |
| − | ==Introduction==
| |
| − | Compose is a tool for defining and running multi-container Docker applications. With Compose, you use a YAML file to configure your application’s services. Then, with a single command, you create and start all the services from your configuration.
| |
| | | | |
| | | | |
| − | '''Multiple isolated environments on a single host'''<br>
| |
| − | Compose uses a project name to isolate environments from each other. You can make use of this project name in several different contexts:
| |
| − | * on a dev host, to create multiple copies of a single environment, such as when you want to run a stable copy for each feature branch of a project
| |
| − | * on a CI server, to keep builds from interfering with each other, you can set the project name to a unique build number
| |
| | | | |
| | | | |
| − | '''Development environments'''<br>
| |
| − | When you’re developing software, the ability to run an application in an isolated environment and interact with it is crucial. The Compose command line tool can be used to create the environment and interact with it.
| |
| − | * The Compose file provides a way to document and configure all of the application’s service dependencies (databases, queues, caches, web service APIs, etc). Using the Compose command line tool you can create and start one or more containers for each dependency with a single command (docker-compose up).
| |
| − | * Together, these features provide a convenient way for developers to get started on a project. Compose can reduce a multi-page “developer getting started guide” to a single machine readable Compose file and a few commands.
| |
| − |
| |
| − |
| |
| − | '''Automated testing environments'''<br>
| |
| − | An important part of any Continuous Deployment or Continuous Integration process is the automated test suite. Automated end-to-end testing requires an environment in which to run tests. Compose provides a convenient way to create and destroy isolated testing environments for your test suite. By defining the full environment in a Compose file, you can create and destroy these environments in just a few commands:
| |
| − |
| |
| − |
| |
| − | Source: https://docs.docker.com/compose/overview/
| |
| − |
| |
| − | ==Docker compose vs docker stack==
| |
| − | In recent releases, a few things have happened in the Docker world. Swarm mode got integrated into the Docker Engine in 1.12, and has brought with it several new tools. Among others, it’s possible to make use of docker-compose.yml files to bring up stacks of Docker containers, without having to install Docker Compose.
| |
| − |
| |
| − | The command is called docker stack, and it looks exactly the same to docker-compose.
| |
| − | Both docker-compose and the new docker stack commands can be used with docker-compose.yml files which are written according to the specification of version 3. For your version 2 reliant projects, you’ll have to continue using docker-compose. If you want to upgrade, it’s not a lot of work though.
| |
| − |
| |
| − | As docker stack does everything docker compose does, it’s a safe bet that docker stack will prevail. This means that docker-compose will probably be deprecated and won’t be supported eventually.
| |
| − |
| |
| − | However, switching your workflows to using docker stack is neither hard nor much overhead for most users. You can do it while upgrading your docker compose files from version 2 to 3 with comparably low effort.
| |
| − |
| |
| − | If you’re new to the Docker world, or are choosing the technology to use for a new project - by all means, stick to using docker stack deploy.
| |
| − |
| |
| − | Source: https://vsupalov.com/difference-docker-compose-and-docker-stack/
| |
| − |
| |
| − | ==Install==
| |
| − |
| |
| − | <pre>
| |
| − | sudo curl -L https://github.com/docker/compose/releases/download/1.21.2/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose
| |
| − | sudo chmod +x /usr/local/bin/docker-compose
| |
| − | </pre>
| |
| − |
| |
| − | <pre>
| |
| − | # docker-compose --version
| |
| − | docker-compose version 1.21.2, build a133471
| |
| − | </pre>
| |
| − |
| |
| − | <br>
| |
| − | <br>
| |
| | <br> | | <br> |
| | | | |
| | | | |
| − | ==How to use docker-compose==
| |
| | | | |
| | | | |
| − | <pre>
| |
| − | $ mkdir wp-example
| |
| − | $ cd wp-example
| |
| − | $ mkdir wordpress
| |
| − | $ touch docker-compose.yml
| |
| − | </pre>
| |
| | | | |
| − | <pre>
| |
| − | [wp-example]# ll
| |
| − | total 8
| |
| − | -rw-r--r-- 1 root root 148 Jun 23 23:09 docker-compose.yml
| |
| − | drwxr-xr-x 2 root root 4096 Jun 23 22:58 wordpress
| |
| − | </pre>
| |
| | | | |
| − | <pre>
| + | =Swarm Classic VS Swarm mode= |
| − | $ cd wordpress
| + | Docker has been innovating at quite a dramatic pace, and focussing on making their technology easier to deploy, and applicable for a wider range of use cases. One of the features that has received the highest level of focus is Clustering/Orchestration. In Docker language, that means Swarm. |
| − | $ touch Dockerfile
| |
| − | $ touch example.html
| |
| − | </pre>
| |
| − | | |
| − | <pre>
| |
| − | [wordpress]# ll
| |
| − | total 8
| |
| − | -rw-r--r-- 1 root root 159 Jun 23 22:58 Dockerfile
| |
| − | -rw-r--r-- 1 root root 18 Jun 23 22:44 example.html
| |
| − | </pre>
| |
| | | | |
| − | <syntaxhighlight lang="Python">
| + | source: https://www.linkedin.com/pulse/docker-swarm-vs-mode-neil-cresswell/ |
| − | FROM wordpress:latest
| |
| − | COPY ["./example.html","/var/www/html/example.html"]
| |
| − | VOLUME /var/www/html
| |
| − | ENTRYPOINT ["docker-entrypoint.sh"]
| |
| − | CMD ["apache2-foreground"]
| |
| − | </syntaxhighlight>
| |
| | | | |
| | + | ==Swarm classic== |
| | + | Prior to Docker 1.12 Swarm (Classic) existed as a standalone product, it relied on a complicated setup of external service discovery systems (eg consul) and a dedicated set of containers which ran as the swarm controllers. Load balancing network traffic across containers required external load balancers, and these needed to be integrated with service discovery to function correctly. Standalone Docker hosts were members of a swarm cluster, and the swarm controllers presented the pooled capacity from all hosts as a single “virtual” docker host. By presenting the swarm cluster as a virtual docker host meant that the way you interacted with Swarm was exactly the same way you interacted with a standalone host (docker run, docker ps, docker images, docker volumes), you just directed the commands (using –H=tcp://) at the swarm master IP:Port instead of individual swarm nodes. |
| | | | |
| − | docker-compose.yml | + | A Docker 1.12-es verziója előtt a Swarm (Classic) egy külön álló termék volt, nem volt része a docker engine-nek. A swarm-ot a docker engine-en futó swarm konténerekkel kellett létrehozni. Vo |
| − | <syntaxhighlight lang="C++">
| |
| − | wordpress:
| |
| − | build: ./wordpress
| |
| − | links:
| |
| − | - db:mysql
| |
| − | ports:
| |
| − | - 8080:80
| |
| | | | |
| − | db:
| + | ==Swarm mode== |
| − | image: mariadb
| + | Since releasing Docker 1.12, and embedding Swarm Mode (I really wish they had called it something else to minimise confusion) into the core Docker engine, the functionality and management of swarm has altered dramatically. No longer does the cluster (pool of resources) emulate a virtual docker host, and no longer can you run standard docker engine commands against the swarm cluster, you now need to use specific commands (service create, service inspect, service ps, service ls, service scale etc). If you run Docker engine commands (docker ps) what is returned is a list of containers running on the Docker Swarm Master HOST (not the cluster). If you want to interact with containers that make up a swarm “service”, you need to take multiple steps (service ps, to show the containers, and which host they are on, then change the focus of your docker commands to that host, connect to that host, and then issue the docker commands to manage the containers on that specific host/swarm member). |
| − | environment:
| |
| − | MYSQL_ROOT_PASSWORD: example
| |
| − | </syntaxhighlight>
| |
| | | | |
| − | =SWARM=
| + | The key point of SwarmMode is that it is an overlay engine for running SERVICES, not Containers. In fact, a service actually comprises a number of tasks, with a task being a container and any commands to execute within the container (but a task might also be a VM in the future). |
| | | | |
| − | ==Introduction==
| + | One of the major enhancements in Swarm mode is the load balancing, which is now built-in; now when you publish service, exposed ports will automatically be load balanced across the containers (tasks though, remember) that comprise that service. You don’t need to configure any additional load balancing. This change makes it incredibly easy to, say for instance, scale a nginx service from 1 worker task (container) to 10. |
| − | A swarm is a group of machines that are running Docker and joined into a cluster. After that has happened, you continue to run the Docker commands you’re used to, but now they are executed on a cluster by a swarm manager. The machines in a swarm can be physical or virtual. After joining a swarm, they are referred to as nodes.
| |
| | | | |
| − | Source: https://docs.docker.com/get-started/part4/#introduction
| + | So, if you are using Swarm mode in Docker 1.12, you need to stop thinking about Containers (and trying to interact with the containers that make up a service) and rather, manage the service and tasks. |
| | | | |
| − | =Kubernetes=
| + | In Portainer.io, we exhibit the same behaviour as above, so if you click on “containers” you will only see the container |
vim /etc/default/grub
2- Add Line below in GRUB_CMDLINE_LINUX systemd.unified_cgroup_hierarchy=0
Docker has been innovating at quite a dramatic pace, and focussing on making their technology easier to deploy, and applicable for a wider range of use cases. One of the features that has received the highest level of focus is Clustering/Orchestration. In Docker language, that means Swarm.
Prior to Docker 1.12 Swarm (Classic) existed as a standalone product, it relied on a complicated setup of external service discovery systems (eg consul) and a dedicated set of containers which ran as the swarm controllers. Load balancing network traffic across containers required external load balancers, and these needed to be integrated with service discovery to function correctly. Standalone Docker hosts were members of a swarm cluster, and the swarm controllers presented the pooled capacity from all hosts as a single “virtual” docker host. By presenting the swarm cluster as a virtual docker host meant that the way you interacted with Swarm was exactly the same way you interacted with a standalone host (docker run, docker ps, docker images, docker volumes), you just directed the commands (using –H=tcp://) at the swarm master IP:Port instead of individual swarm nodes.
A Docker 1.12-es verziója előtt a Swarm (Classic) egy külön álló termék volt, nem volt része a docker engine-nek. A swarm-ot a docker engine-en futó swarm konténerekkel kellett létrehozni. Vo
Since releasing Docker 1.12, and embedding Swarm Mode (I really wish they had called it something else to minimise confusion) into the core Docker engine, the functionality and management of swarm has altered dramatically. No longer does the cluster (pool of resources) emulate a virtual docker host, and no longer can you run standard docker engine commands against the swarm cluster, you now need to use specific commands (service create, service inspect, service ps, service ls, service scale etc). If you run Docker engine commands (docker ps) what is returned is a list of containers running on the Docker Swarm Master HOST (not the cluster). If you want to interact with containers that make up a swarm “service”, you need to take multiple steps (service ps, to show the containers, and which host they are on, then change the focus of your docker commands to that host, connect to that host, and then issue the docker commands to manage the containers on that specific host/swarm member).
The key point of SwarmMode is that it is an overlay engine for running SERVICES, not Containers. In fact, a service actually comprises a number of tasks, with a task being a container and any commands to execute within the container (but a task might also be a VM in the future).
One of the major enhancements in Swarm mode is the load balancing, which is now built-in; now when you publish service, exposed ports will automatically be load balanced across the containers (tasks though, remember) that comprise that service. You don’t need to configure any additional load balancing. This change makes it incredibly easy to, say for instance, scale a nginx service from 1 worker task (container) to 10.
So, if you are using Swarm mode in Docker 1.12, you need to stop thinking about Containers (and trying to interact with the containers that make up a service) and rather, manage the service and tasks.
In Portainer.io, we exhibit the same behaviour as above, so if you click on “containers” you will only see the container
