Как да наблюдавате PostgreSQL, работещ вътре в Docker контейнер:Част първа

Наблюдението е действието на гледане и проверка за определен период от време, за да се види как се развива и изпълнява това, което наблюдавате. Правите го, за да можете да правите всички необходими промени, за да сте сигурни, че нещата работят правилно. От съществено значение е процесите да се наблюдават, за да се получи добра представа за дейностите, които се извършват, за да се планира, организира и изпълнява ефективно решение.

Docker е програма, създадена да работи като конструктор, готов да отговори на въпроса „Ще работи ли софтуерът на моята машина?“ Той основно сглобява различни части заедно, създавайки модел, лесен за съхранение и транспорт. Моделът, известен още като контейнер, може да бъде изпратен до всеки компютър, на който е инсталиран Docker.

В тази статия ще се запознаем с Docker, като опишем някои начини за конфигуриране и ще ги сравним. Освен това PostgreSQL влиза в действие и ние ще го разположим в Docker контейнер по интелигентен начин и накрая ще видим предимствата, които ClusterControl може да предостави, за да наблюдаваме ключови показатели за PostgreSQL и ОС извън него.

Общ преглед на Docker

Когато Docker стартира, той създава нова мрежова връзка, за да позволи предаването на данни между две крайни точки, наречени мост, и това е мястото, където новите контейнери се съхраняват по подразбиране.

По-долу ще видим подробности за този мост и ще обсъдим защо не е добра идея да се използва в производството.

$ docker network inspect bridge

Моля, обърнете внимание на вградените опции, защото ако стартирате контейнер без да посочите желаната мрежа, ще се съгласите с него.

При тази мрежова връзка по подразбиране губим някои добри предимства на работата в мрежа, като DNS. Представете си, че искате да получите достъп до Google, кой адрес предпочитате, www.google.com или 172.217.165.4?

Не знам за вас, но аз предпочитам по-ранния избор и, честно казано, не въвеждам „www.“.

Дефинирана от потребителя мостова мрежа

Така че искаме DNS в нашата мрежова връзка и ползата от изолацията, защото си представете сценария, при който разгръщате различни контейнери в една и съща мрежа.

Когато създаваме Docker контейнер, можем да му дадем име или Docker го прави вместо нас, като произволно прави две думи, свързани с подчертаване или „_“.

Ако не използваме дефинирана от потребителя мостова мрежа, в бъдеще може да възникне проблем в средата на IP адресите, защото очевидно не сме машини и не забравяйте, че тези стойности могат да бъдат твърди и податливи на грешки.

Създаването на персонализиран мост или потребителски дефинирана мостова мрежа е много лесно.

Преди да създадем първия, за да разберем по-добре процеса, нека отворим нов терминал, да напишем Linux команда от пакета iproute2 и да забравим за него досега.

$ ip monitor all

Този терминал вече ще слуша мрежовата активност и ще се показва там.

Може да сте виждали команди като “ifconfig” или “netstat” преди и аз ви казвам, че те са остарели от 2001 г. Пакетът net-tools все още се използва широко, но вече не се актуализира.

Сега е време да създадем първата си персонализирана мрежа, така че отворете друг терминал и въведете:

$ docker network create --driver bridge br-db

Тази много дълга комбинация от букви и цифри се нарича UUID или универсален уникален идентификатор. По същество това означава, че мрежата е създадена успешно.

Даденото име за нашата първа мрежа, създадена ръчно, е „br-db“ и трябва да бъде в финала на командата, но преди това имаме аргумента „-driver“, а след това стойността „bridge“ , защо?

В изданието на Общността Docker предоставя три различни налични драйвера:мост, хост и нито един. В момента на създаване, като този, по подразбиране е мост и не е необходимо да се посочва, но ние научаваме за него.

Ако сте направили всичко с мен, погледнете другия терминал, защото ще ви обясня какво се случва.

Docker създаде мрежата, наречена “br-db”, но тя се нарича само така от него.

От другата страна на създадения персонализиран мост има друг слой, ОС. Даденото име за същата мостова мрежа се е променило и става представяне на номенклатурата за мост, „br“, последвано от първите 12 знака от стойността на UUID по-горе, в червено.

С новата ни мрежова връзка имаме подмрежа, шлюз и излъчване.

Шлюзът, както подсказва името, е мястото, където целият трафик на пакети се случва между крайните точки на моста и се нарича „inet“ за ОС, както можете да видите.

Broadcast стои в последния IP адрес и отговаря за изпращането на същия трафик от данни за всички IP адреси в подмрежата, когато е необходимо.

Те винаги присъстват в мрежовите връзки и затова имаме в началото на изхода стойността „[ADDR]“. Тази стойност представлява промени в IP адреса и е като събитие, което се задейства за наблюдение на мрежовата активност, защото създадохме нова мрежова връзка!

Docker контейнер

Моля, посетете Docker Hub и вижте, че това, което е там, е известно като Docker Image и е основно скелетът на контейнера (модела).

Docker изображенията се генерират от Dockerfiles и съдържат цялата информация, необходима за създаване на контейнер, за да се улесни поддръжката и персонализирането му.

Ако погледнете внимателно в Docker Hub, лесно ще видите, че изображението на PostgreSQL, наречено postgres, има различни тагове и версии и ако не посочите една от тях, ще се използва по подразбиране, най-новата, но може би в бъдещето, ако имате нужда от различни контейнери на PostgreSQL да работят заедно, може да искате те да са в една и съща версия.

Нека създадем нашия първи десен контейнер сега, запомнете необходимостта от аргумента „--network“, или той ще бъде разгърнат в моста по подразбиране.

$ docker container run --name postgres-1 --network br-db -e POSTGRES_PASSWORD=5af45Q4ae3Xa3Ff4 -p 6551:5432 -d postgres

Отново UUID, успех и в другия терминал какво става?

Промените в мрежовия интерфейс са събитието, което се случва в момента, или просто „[LINK]“. Всичко след „veth“ можете да забравите, повярвайте ми, стойността винаги се променя, когато контейнерът се рестартира или се случи нещо подобно.

Другата опция "-e POSTGRES_PASSWORD=?" означава Environment и е достъпен само когато се изпълняват PostgreSQL контейнери, той конфигурира паролата за супер потребителския акаунт в базата данни, наречен postgres.

Publish е дългото име за параметъра „-p 6551:5432“ и по същество прави порта на ОС 6551 двупосочен към порт 5432 на контейнера.

Последна, но не по-малко важна, е опцията Detach, „-d“, и това, което прави, е да кара контейнера да работи независимо от този терминал.

Името на изображението на Docker трябва да бъде накрая, като следва същия модел на създаване на мрежата, като има всички аргументи и опции вляво и накрая най-важното нещо, в този случай, името на изображението.

Не забравяйте, че контейнерите се държат в мрежовата подмрежа, стоящи на IP адреси, разрешени за всеки един от тях, и никога няма да бъдат на първия или последния адрес, защото Gateway и Broadcast ще бъдат винаги там.

Показахме подробностите за създадения мост и сега ще се показват от всяка една от крайните точки, тези детайли, съхранявани от тях.

$ docker network inspect br-db

$ brctl show

Както можете да видите, имената на мрежата и контейнерите се различават, като вторият се разпознава като интерфейс от ОС, наречен „veth768ff71“, а оригиналното име, дадено от нас „postgres-1“ за Docker.

В командата Docker е възможно да се отбележи IP адресът за контейнера, създаден по-рано, подмрежата, съответстваща на това, което се е появило в другия терминал, отворен преди минути, и накрая празните опции за тази персонализирана мрежа.

Командата на Linux „brctl show“ е част от пакета bridge-utils и както подсказва името, целта й е да предостави набор от инструменти за конфигуриране и управление на Linux Ethernet мостове.

Друга персонализирана мостова мрежа

Скоро ще обсъдим DNS, но беше много добре да направим нещата лесни за нас в бъдеще. Страхотните конфигурации са склонни да улеснят живота на DBA в бъдеще.

С мрежите е същото, така че можем да променим начина, по който ОС разпознава адреса и името на подмрежата, като добавим още аргументи по време на създаване.

$ docker network create --driver bridge --subnet 172.23.0.0/16 -o “com.docker.network.bridge.name”=”bridge-host” bridge-docker

$ ip route show

С тази команда на Linux можем да видим почти същото нещо като другата команда по-рано, но сега вместо да изброяваме „veth“ интерфейсите за всяка мрежа, ние просто имаме тази „linkdown“, показваща онези, които са празни.

Желаният адрес на подмрежа е посочен като аргумент и подобно на опцията Environment за създаване на контейнер, за мрежа имаме „-o“, последвано от двойката ключ и стойност. В този случай казваме на Docker, за да каже на ОС, че трябва да извика мрежата като „мост-хост“.

Съществуването на тези три мрежи може да се провери и в Docker, просто въведете:

$ docker network ls

Вече обсъдихме по-рано, че стойностите на тези „вех“ за контейнерите нямат значение и ще ви покажа на практика.

Упражнението се състои в проверка на текущата стойност, след това рестартиране на контейнера, след което проверка отново. За целта ще ни трябва комбинация от команди на Linux, използвани преди, и такива на Docker, които са нови тук, но много прости:

$ brctl show
$ docker container stop postgres-1
$ docker container start postgres-1
$ brctl show

Когато контейнерът е спрян, IP адресът трябва да бъде освободен, за да получи нов, ако е необходимо, и това е напомняне за това как DNS може да бъде важен.

Операционната система дава тези имена на интерфейсите всеки път, когато контейнер стои в IP адрес и те се генерират с помощта на пакета iptables, който скоро ще бъде заменен от новата рамка, наречена nftables.

Не се препоръчва да променяте тези правила, но съществуват инструменти, които да помогнат при визуализирането им, ако е необходимо, като dockerveth.

Правила за рестартиране на контейнера

Когато рестартираме програмата Docker или дори компютъра, създадените от него мрежи се запазват в ОС, но празни.

Контейнерите имат това, което се нарича политика за рестартиране на контейнера, и това е друг много важен аргумент, посочен по време на създаване. PostgreSQL, като производствена база данни, неговата наличност е от решаващо значение и ето как Docker може да помогне с нея.

$ docker container run --name postgres-2 --network bridge-docker --restart always -e POSTGRES_PASSWORD=5af45Q4ae3Xa3Ff4 -p 6552:5432 -d postgres

Освен ако не го спрете ръчно, този контейнер „postgres-2“ ще бъде винаги наличен.

За да го разберете по-добре, ще се покажат работещите контейнери и програмата Docker ще се рестартира, след това отново първата стъпка:

$ docker container ls
$ systemctl restart docker
$ docker container ls

Само контейнерът “postgres-2” работи, другият контейнер “postgres-1” не стартира сам. Повече информация за него можете да видите в документацията на Docker.

Система за имена на домейни (DNS)

Едно от предимствата на User-Defined Bridge Network е организацията, разбира се, защото можем да създадем толкова, колкото искаме, за да стартираме нови контейнери и дори да свързваме стари, но друго предимство, което нямаме, използвайки моста по подразбиране на Docker, е DNS.

Когато контейнерите трябва да комуникират един с друг, може да бъде болезнено за DBA да запомни IP адресите и ние го обсъдихме по-рано, показвайки примера на www.google.com и 172.217.165.4. DNS решава този проблем безпроблемно, като прави възможно взаимодействието с контейнери, използвайки техните имена, дадени от нас по време на създаване, като "postgres-2", вместо IP адреса "172.23.0.2".

Да видим как работи. Ще създадем друг контейнер само за демонстрационни цели в същата мрежа, наречена “postgres-3”, след това ще инсталираме пакета iputils-ping за предаване на пакети данни към контейнера “postgres-2”, използвайки името му, разбира се .

$ docker container run --name postgres-3 --network bridge-docker --restart always -e POSTGRES_PASSWORD=5af45Q4ae3Xa3Ff4 -p 6553:5432 -d postgres
$ docker container exec -it postgres-3 bash

За по-добро разбиране нека го разделим на части, в следващите изходи синята стрелка ще показва кога командата се изпълнява вътре в контейнер и в червено в ОС.

$ apt-get update && apt-get install -y iputils-ping

$ ping postgres-2

Резюме

PostgreSQL работи вътре в Docker и неговата наличност е гарантирана досега. Когато се използват в рамките на потребителски дефинирана мостова мрежа, контейнерите могат да се управляват по-лесно с много предимства като DNS, персонализирани адреси на подмрежи и имена на ОС за мрежите.

Видяхме подробности за Docker и колко е важно да сте наясно с актуализираните пакети и рамки в операционната система.