Changes

Docker

1,353 bytes added, 22:21, 23 February 2020
no edit summary
[[Docker basic]]
 
[[Docker Compose]]
[[Docker Machine]]
[[Docker Swarm SlassicClassic]]
[[Docker Swarm Mode]]
 
[[Docker Swarm management]]
 
[[Docker volume orchestration]]
 
[[Docker Swarm on AWS]]
 
[[Stateful load-balancing in swarm]]
 
[[Centralized logging in swarm]]
 
[[Metrics and Monitoring in swarm]]
 
[[Auto-scaling swarm]]
 
[[Kafka with ELK on swarm]]
 
[[Java EE application with docker]]<br>
Itt egy tipikus, produkciós docker architektúrát mutatunk be egy két lábas JBoss cluster-el, de swarm nélkül
 
[[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.
 
 
<br>
=Docker on Fedora 31=
https://www.reddit.com/r/linuxquestions/comments/dn2psl/upgraded_to_fedora_31_docker_will_not_work/<br>
https://fedoraproject.org/wiki/Changes/CGroupsV2<br
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.
 
 
1-
 
vim /etc/default/grub
2- Add Line below in GRUB_CMDLINE_LINUX systemd.unified_cgroup_hierarchy=0
<pre>
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
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>
 
3- Then :
 
# grub2-mkconfig
 
4- Restart your PC
 
 
 
 
 
 
 
 
<br>
 
 
 
 
 
=Swarm Classic VS Swarm mode=
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.
 
source: https://www.linkedin.com/pulse/docker-swarm-vs-mode-neil-cresswell/
==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.
 
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
==Swarm mode==
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 running on the Docker Master Host, not the containers running across all hosts in a swarm. You need to click on Services and then drill down into tasks to see the backing containers and where they are running (but you still cannot interact with them). We are currently investigating a workaround where we can concurrently query each host that makes up a swarm cluster and create a single aggregated view, but this would be specific to Portainer and not a native Docker feature.