Дали Докер е играчка или не? Или сепак е вистина?

Здраво на сите!

Навистина сакам да навлезам директно на темата, но би било поправилно да кажам малку за мојата приказна:

Влегување

Јас сум програмер со искуство во развој на frontend апликации за една страница, scala/java и nodejs на серверот.

Доста долго време (дефинитивно неколку или три години) бев на мислење дека Docker е мана од небото и воопшто многу кул алатка и апсолутно секој развивач треба да може да ја користи. И од ова произлегува дека секој развивач треба да има инсталирано Docker на својата локална машина. Што е со моето мислење, погледнете ги слободните работни места што се објавени на истото ч. Секој втор содржи спомнување на docker, и ако го поседувате, ова ќе биде вашата конкурентна предност 😉

На мојот пат, запознав многу луѓе, со нивните различни ставови кон Докер и неговиот екосистем. Некои рекоа дека ова е погодно нешто што гарантира функционалност на повеќе платформи. На вторите не им беше јасно зошто да трчаат во контејнери и каков профит ќе има од тоа, на третите воопшто не им беше грижа и не се замараа (само го напишаа кодот и си отидоа дома - им завидувам, по начин :)

Причини за употреба

Зошто користев докер? Веројатно од следниве причини:

• стартување на базата на податоци, 99% од апликациите ги користат
• лансирање на nginx за дистрибуција на предниот дел и прокси на задниот дел
• можете да ја спакувате апликацијата во докер слика, на овој начин мојата апликација ќе работи секаде каде што постои докер, проблемот со дистрибуцијата се решава веднаш
• откривање на услугата надвор од кутијата, можете да креирате микросервиси, секој контејнер (поврзан на заедничка мрежа) лесно може да стигне до друг преку псевдоним, многу удобен
• Забавно е да се создаде контејнер и да се „игра“ во него.

Она што секогаш НЕ ми се допаѓа кај докер:

• За да може мојата апликација да работи, ми треба самиот Docker на серверот. Зошто ми треба ова ако моите апликации работат на jre или nodejs и околината за нив е веќе на серверот?
• ако сакам да ја стартувам мојата (приватна) локално изградена слика на оддалечен сервер, тогаш ми треба сопствено складиште за докер, ми треба регистарот да работи некаде и исто така треба да го конфигурирам https, бидејќи docker cli работи само преку https. О, по ѓаволите... има опции, се разбира, да ја зачувате сликата локално преку docker save и само испратете ја сликата преку scp... Но, тоа се многу движења на телото. И покрај тоа, изгледа како решение за „патерици“ додека не се појави вашето сопствено складиште
• docker-compose. Потребно е само за пуштање контејнери. Тоа е се. Тој не може да направи ништо друго. Docker-compose има еден куп верзии на неговите датотеки, своја синтакса. Колку и да е декларативно, не сакам да им ја читам документацијата. Нема да ми треба никаде на друго место.
• кога работат во тим, повеќето луѓе пишуваат Dockerfile многу криво, не разбираат како се кешира, додаваат сè што им треба и не треба на сликата, наследуваат од слики што не се во Dockerhub или приватно складиште, создаваат некои docker-compose датотеки со бази на податоци и ништо не опстојува. Во исто време, програмерите гордо изјавуваат дека Docker е кул, сè работи локално за нив, а HR најважно пишува на огласот: „Ние користиме Docker и ни треба кандидат со такво работно искуство“.
• Постојано ме прогонуваат мислите за подигање на сè во Docker: postgresql, kafka, redis. Штета е што не функционира сè во контејнери, не е сè лесно да се конфигурира и да работи. Ова е поддржано од трети лица програмери, а не од самите продавачи. И, патем, веднаш се поставува прашањето: продавачите не се грижат за одржување на нивните производи во Docker, зошто е ова, можеби тие знаат нешто?
• Прашањето секогаш се поставува за постојаноста на контејнерските податоци. и тогаш мислите, дали треба само да го монтирам директориумот на домаќинот или да создадам докер волумен или да направам контејнер со податоци што е сега deprecated? Ако монтирам директориум, тогаш треба да се уверам дека uid и gid на корисникот во контејнерот се совпаѓаат со ID на корисникот кој го стартувал контејнерот, инаку датотеките создадени од контејнерот ќе се креираат со права на root. Ако користам volume тогаш податоците едноставно ќе се креираат во некои /usr/* и ќе има иста приказна со уид и гид како во првиот случај. Ако стартувате компонента од трета страна, треба да ја прочитате документацијата и да го побарате одговорот на прашањето: „во кои директориуми на контејнери компонентата запишува датотеки?

Отсекогаш не ми се допаѓаше тоа што предолго морав да се чепкам со Докер во почетната фаза: Сфатив како да стартувам контејнери, од кои слики да стартувам, направив Make-датотеки што содржеа псевдоними на долгите команди на Docker. Го мразев docker-compose затоа што не сакав да научам друга алатка во екосистемот на докер. И docker-compose up Ми пречеше, особено ако се уште се сретнаа таму build конструкции, наместо веќе составени слики. Сè што навистина сакав беше само да направам производ ефикасно и брзо. Но, не можев да сфатам како да користам докер.

Ви го претставуваме Ansible

Неодамна (пред три месеци) работев со тим на DevOps, чиј речиси секој член имаше негативен став кон Docker. Од причини:

• docker правила iptables (иако можете да го оневозможите во daemon.json)
• docker е кабриолет и нема да го пуштиме во производство
• ако докер демонот падне, тогаш сите контејнери со инфраструктура паѓаат соодветно
• нема потреба од докер
• зошто докер ако има Ansible и виртуелни машини

На истата работа се запознав со уште една алатка - Ansible. Слушнав за тоа еднаш, но не се обидов да напишам свои книги. И сега почнав да ги пишувам моите задачи и тогаш мојата визија целосно се промени! Затоа што сфатив: Ansible има модули за водење на исти докер-контејнери, градби на слики, мрежи итн., а контејнерите може да се извршуваат не само локално, туку и на оддалечени сервери! Моето задоволство немаше граници - најдов НОРМАЛНА алатка и ги фрлив моите датотеки Makefile и docker-compose, тие беа заменети со yaml задачи. Кодот беше намален со користење на конструкции како loop, when, Итн

Докер за водење на компоненти од трети страни како бази на податоци

Неодамна се запознав со ssh тунелите. Се испостави дека е многу лесно да се „препрати“ пристаништето на оддалечен сервер до локално пристаниште. Далечинскиот сервер може да биде или машина во облакот или виртуелна машина што работи во VirtualBox. Ако на мојот колега или на мене ни треба база на податоци (или некоја друга компонента од трета страна), можеме едноставно да го стартуваме серверот со оваа компонента и да го исклучиме кога серверот не е потребен. Препраќањето на портата го дава истиот ефект како базата на податоци што работи во докер контејнер.

Оваа команда ја препраќа мојата локална порта на оддалечен сервер што работи postgresql:

ssh -L 9000:localhost:5432 [заштитена по е-пошта]

Користењето на далечински сервер го решава проблемот со развојот на тимот. Таквиот сервер може да го користат неколку програмери одеднаш; тие не треба да можат да го конфигурираат postgresql, да го разбираат Docker и другите сложености. На оддалечен сервер, можете да ја инсталирате истата база на податоци во самиот Docker, ако е тешко да се инсталира одредена верзија. Сè што им е потребно на програмерите е да обезбедат ssh пристап!

Неодамна прочитав дека SSH тунелите се ограничена функционалност на обичен VPN! Можете едноставно да инсталирате OpenVPN или други имплементации на VPN, да ја поставите инфраструктурата и да им ја дадете на програмерите за употреба. Ова е толку кул!

За среќа, AWS, GoogleCloud и други ви даваат една година бесплатно користење, затоа искористете ги! Тие се евтини ако ги исклучите кога не се во употреба. Секогаш се прашував зошто ќе ми треба далечински сервер како gcloud, изгледа ги најдов.

Како локална виртуелна машина, можете да го користите истиот Alpine, кој активно се користи во контејнери за докер. Па, или некои други лесни дистрибуции за да се подигне машината побрзо.

Крајна линија: можете и треба да извршувате бази на податоци и други инфраструктурни добрини на оддалечени сервери или во виртуелна кутија. Не ми треба докер за овие цели.

Малку за докерските слики и дистрибуцијата

Веќе напишав статью во кој сакав да пренесам дека користењето на докер слики не дава никаква гаранција. Докерските слики се потребни само за да се создаде контејнер за докер. Ако надградувате докерска слика, тогаш се надградувате за да користите докер контејнери и ќе ги користите само.

Дали сте виделе некаде каде развивачите на софтвер ги пренесуваат своите производи само во докерска слика?
Резултатот од повеќето производи се бинарни датотеки за одредена платформа; тие едноставно се додаваат на сликата на докерот, која е наследена од саканата платформа. Дали некогаш сте се запрашале зошто има толку многу слични слики на dockerhub? Внесете nginx на пример, ќе видите 100500 слики од различни луѓе. Овие луѓе не го развија самиот nginx, тие едноставно додадоа официјален nginx на нивниот докер имиџ и го зачинија со свои конфигурации за практичноста на лансирањето контејнери.

Во принцип, можете едноставно да го складирате во tgz, ако некој треба да го изврши во docker, тогаш нека го додаде tgz во Dockerfile, да наследи од саканата околина и да создаде дополнителни бухти кои не ја менуваат самата апликација во tgz. Секој што ќе создаде докер слика ќе знае што е tgz и што му треба за да работи. Вака користам докер тука

Крајна линија: не ми треба докер регистар, ќе користам некој вид S3 или само складирање датотеки како Google Drive/dropbox

Докер во CI

Сите фирми за кои сум работел се слични. Тие се обично намирници. Тоа е, тие имаат една апликација, еден стек технологија (добро, можеби неколку или три програмски јазици).

Овие компании користат докер на нивните сервери каде што работи процесот CI. Прашање: Зошто треба да градите проекти во докер контејнер на вашите сервери? Зошто само да не подготвите средина за изградбата, на пример, да напишете Ansible Playbook која ќе ги инсталира потребните верзии на nodejs, php, jdk, копирајте ssh клучеви итн. на серверот во кој ќе се одвива изградбата?

Сега разбрав дека ова си пука во нога, бидејќи докер не носи никаков профит со својата изолација. Проблеми што ги сретнав со CI во докерот:

• повторно ви треба докер слика за да изградите. треба да барате слика или да напишете своја сопствена dockerfile.
• 90% дека треба да препратите некои ssh клучеви, тајни податоци што не сакате да ги запишете на сликата на докерот.
• контејнерот се создава и умира, сите кешови се губат заедно со него. следната изработка повторно ќе ги преземе сите зависности од проектот, што одзема многу време и е неефикасно, а времето е пари.

Програмерите не градат проекти во докер-контејнери (некогаш бев таков обожавател, навистина, се жалам за себе во минатото xD). Во java е можно да имате неколку верзии и да ги промените со една команда на онаа што ви треба сега. Во nodejs е исто, има nvm.

Излез

Верувам дека докерот е многу моќна и флексибилна алатка, ова е неговиот недостаток (звучи чудно, да). Со негова помош, компаниите можат лесно да се закачат на него и да го користат онаму каде што е потребно, а не. Програмерите ги лансираат своите контејнери, некои од нивните околини, а потоа сето тоа непречено се влева во CI и производство. Тимот на DevOps пишува некој вид на код за да ги стартува овие контејнери.

Користете само докер вклучено најновиот фаза во вашиот работен тек, не го влечете во проектот на почетокот. Тоа нема да ви ги реши деловните проблеми. Тој само ќе ги премести проблемите на ДРУГО ниво и ќе понуди свои решенија, вие ќе работите двојна работа.

Кога е потребен докер: Дојдов до заклучок дека docker е многу добар во оптимизирање на даден процес, но не и во градење на основна функционалност

Ако сепак одлучите да користите докер, тогаш:

• бидете исклучително внимателни
• не ги принудувајте програмерите да користат докер
• локализирајте ја неговата употреба на едно место, не ширете ја низ сите складишта на Dockfile и docker-compose

PS:

• Неодамна наидов пакувач и тие велат дека работи многу добро со Ansible и ви овозможува да го обедините процесот на градење слики (вклучувајќи ја и докерската слика)
• исто така за докер, интересна статија

Ви благодарам што прочитавте, ви посакувам транспарентни одлуки во вашите работи и продуктивни работни денови!

Извор: www.habr.com