Laruan ba si Docker o hindi? O totoo pa rin?

Kumusta sa lahat!

Gusto ko talagang dumiretso sa paksa, ngunit mas tama na magkuwento ng kaunti tungkol sa aking kuwento:

Pagpasok

Ako ay isang programmer na may karanasan sa pagbuo ng mga frontend na single page application, scala/java at nodejs sa server.

Sa loob ng mahabang panahon (tiyak na dalawa o tatlong taon), naniniwala ako na ang Docker ay manna mula sa langit at sa pangkalahatan ay isang napaka-cool na tool at talagang lahat ng developer ay dapat na magamit ito. At mula rito, sinusunod nito na ang bawat developer ay dapat magkaroon ng Docker na naka-install sa kanilang lokal na makina. What about my opinion, tignan mo yung mga bakante na nakalagay sa same hh. Ang bawat segundo ay naglalaman ng pagbanggit ng docker, at kung pagmamay-ari mo ito, ito ang iyong magiging competitive advantage 😉

Sa aking paglalakbay, nakilala ko ang maraming tao, na may iba't ibang mga saloobin sa Docker at sa ecosystem nito. Ang ilan ay nagsabi na ito ay isang maginhawang bagay na ginagarantiyahan ang cross-platform functionality. Ang pangalawa ay hindi naiintindihan kung bakit sila dapat tumakbo sa mga lalagyan at kung ano ang kikitain mula dito, ang pangatlo ay walang pakialam at hindi nag-abala (sinulat lang nila ang code at umuwi - naiinggit ako sa kanila, sa pamamagitan ng paraan :)

Mga dahilan para sa paggamit

Bakit ko ginamit ang docker? Malamang sa mga sumusunod na dahilan:

• paglunsad ng database, 99% ng mga application ang gumagamit ng mga ito
• paglulunsad ng nginx para sa pamamahagi ng frontend at pag-proxy sa backend
• maaari mong i-package ang application sa isang docker na imahe, sa ganitong paraan gagana ang aking application saanman umiiral ang docker, ang problema sa pamamahagi ay nalutas kaagad
• pagtuklas ng serbisyo sa labas ng kahon, maaari kang lumikha ng mga microservice, ang bawat lalagyan (nakakonekta sa isang karaniwang network) ay madaling maabot ang isa pa sa pamamagitan ng isang alias, napaka-maginhawa
• Nakakatuwang gumawa ng lalagyan at "maglaro" dito.

Ang lagi kong AYAW sa docker:

• Upang gumana ang aking aplikasyon, kailangan ko mismo ng Docker sa server. Bakit ko ito kailangan kung ang aking mga aplikasyon ay tumatakbo sa jre o nodejs at ang kapaligiran para sa kanila ay nasa server na?
• kung gusto kong patakbuhin ang aking (pribado) na lokal na binuo na imahe sa isang malayong server, kailangan ko ng sarili kong docker repository, kailangan ko ang pagpapatala upang gumana sa isang lugar at kailangan ko ring i-configure ang https, dahil gumagana lamang ang docker cli sa https. Oh sumpain... may mga pagpipilian, siyempre, upang i-save ang imahe nang lokal sa pamamagitan ng docker save and just send the image via scp... But that’s a lot of body movements. At bukod pa, mukhang isang "saklay" na solusyon hanggang sa lumitaw ang iyong sariling repository
• docker-compose. Ito ay kinakailangan lamang upang magpatakbo ng mga lalagyan. Iyon lang. Wala na siyang magagawa pa. Docker-compose ay may isang grupo ng mga bersyon ng mga file nito, sarili nitong syntax. Kahit gaano pa ito kadeklara, ayaw kong basahin ang kanilang dokumentasyon. Hindi ko na ito kakailanganin kahit saan pa.
• kapag nagtatrabaho sa isang koponan, karamihan sa mga tao ay sumusulat ng isang Dockerfile nang napakaliko, hindi naiintindihan kung paano ito naka-cache, idagdag ang lahat ng kailangan nila at hindi kailangan sa imahe, magmana mula sa mga imahe na wala sa Dockerhub o isang pribadong repositoryo, lumikha ng ilang docker-compose mga file na may mga database at walang nagpapatuloy. Kasabay nito, ipinagmamalaki ng mga developer na idineklara na ang Docker ay cool, lahat ay gumagana nang lokal para sa kanila, at ang HR ay mahalagang nagsusulat sa bakante: "Gumagamit kami ng Docker at kailangan namin ng isang kandidato na may ganoong karanasan sa trabaho."
• Patuloy akong pinagmumultuhan ng mga iniisip tungkol sa pagpapalaki ng lahat sa Docker: postgresql, kafka, redis. Nakakalungkot na hindi lahat ay gumagana sa mga lalagyan, hindi lahat ay madaling i-configure at patakbuhin. Ito ay sinusuportahan ng mga third-party na developer, at hindi ng mga vendor mismo. At sa pamamagitan ng paraan, ang tanong ay agad na lumitaw: ang mga vendor ay hindi nag-aalala tungkol sa pagpapanatili ng kanilang mga produkto sa Docker, bakit ito, marahil ay may alam sila?
• Palaging lumalabas ang tanong tungkol sa pananatili ng data ng container. at pagkatapos ay sa tingin mo, dapat ko bang i-mount na lang ang direktoryo ng host o lumikha ng dami ng docker o gumawa ng lalagyan ng data na ngayon ay deprecated? Kung mag-mount ako ng isang direktoryo, kailangan kong tiyakin na ang uid at gid ng user sa container ay tumutugma sa id ng user na naglunsad ng container, kung hindi, ang mga file na ginawa ng container ay malilikha nang may mga karapatan sa ugat. Kung gagamitin ko volume pagkatapos ay ang data ay malilikha lamang sa ilan /usr/* at magkakaroon ng parehong kuwento na may uid at gid tulad ng sa unang kaso. Kung naglulunsad ka ng isang third-party na bahagi, kailangan mong basahin ang dokumentasyon at hanapin ang sagot sa tanong na: "saang mga direktoryo ng lalagyan nagsusulat ng mga file ang bahagi?"

Palagi kong hindi gusto ang katotohanan na kailangan kong makipag-usap sa Docker nang masyadong mahaba sa paunang yugto: Naisip ko kung paano maglunsad ng mga lalagyan, kung saan ang mga imaheng ilulunsad, gumawa ng mga Makefile na naglalaman ng mga alias sa mahahabang utos ng Docker. Kinasusuklaman ko ang docker-compose dahil ayaw kong matuto ng isa pang tool sa docker ecosystem. AT docker-compose up Naiinis ako, lalo na kung doon pa sila nagkikita build mga konstruksyon, sa halip na mga naka-assemble na larawan. Ang gusto ko lang ay gumawa ng isang produkto nang mahusay at mabilis. Ngunit hindi ko maisip kung paano gamitin ang docker.

Pagpapakilala sa Ansible

Kamakailan lamang (tatlong buwan na ang nakalipas), nagtrabaho ako sa isang koponan ng DevOps, halos bawat miyembro nito ay may negatibong saloobin sa Docker. Para sa mga kadahilanan:

• docker rules iptables (bagama't maaari mo itong i-disable sa daemon.json)
• Ang docker ay buggy at hindi namin ito tatakbo sa produksyon
• kung nag-crash ang docker daemon, lahat ng container na may imprastraktura ay nag-crash nang naaayon
• hindi na kailangan ng docker
• bakit docker kung mayroong Ansible at virtual machine

Sa parehong trabaho, nakilala ko ang isa pang tool - Ansible. Narinig ko ito minsan, ngunit hindi ko sinubukang magsulat ng sarili kong playbook. At ngayon nagsimula akong isulat ang aking mga gawain at pagkatapos ay ganap na nagbago ang aking paningin! Dahil napagtanto ko: Ang Ansible ay may mga module para sa pagpapatakbo ng parehong mga lalagyan ng docker, mga build ng imahe, mga network, atbp., at ang mga lalagyan ay maaaring patakbuhin hindi lamang sa lokal, kundi pati na rin sa mga malalayong server! Walang hangganan ang aking kasiyahan - Nakakita ako ng isang NORMAL na tool at itinapon ang aking mga file na Makefile at docker-compose, pinalitan sila ng mga yaml na gawain. Ang code ay nabawasan sa pamamagitan ng paggamit ng mga konstruksyon tulad ng loop, when, Atbp

Docker para sa pagpapatakbo ng mga bahagi ng third-party gaya ng mga database

Kamakailan ay nakilala ko ang mga ssh tunnels. Ito ay naging napakadaling "ipasa" ang port ng isang malayong server sa isang lokal na port. Ang malayong server ay maaaring maging isang makina sa cloud o isang virtual machine na tumatakbo sa VirtualBox. Kung ang aking kasamahan o ako ay nangangailangan ng isang database (o ilang iba pang bahagi ng third-party), maaari lang nating simulan ang server gamit ang bahaging ito at i-off ito kapag hindi kailangan ang server. Ang pagpapasa ng port ay nagbibigay ng parehong epekto tulad ng isang database na tumatakbo sa isang lalagyan ng docker.

Ipinapasa ng utos na ito ang aking lokal na port sa isang malayong server na tumatakbo sa postgresql:

ssh -L 9000:localhost:5432 [protektado ng email]

Ang paggamit ng isang malayuang server ay malulutas ang problema sa pagbuo ng koponan. Ang nasabing server ay maaaring gamitin ng ilang mga developer nang sabay-sabay; hindi nila kailangang ma-configure ang postgresql, maunawaan ang Docker at iba pang mga intricacies. Sa isang malayong server, maaari mong i-install ang parehong database sa Docker mismo, kung mahirap mag-install ng isang partikular na bersyon. Ang kailangan lang ng mga developer ay magbigay ng ssh access!

Nabasa ko kamakailan na ang mga SSH tunnel ay isang limitadong pag-andar ng isang regular na VPN! Maaari mo lamang i-install ang OpenVPN o iba pang mga pagpapatupad ng VPN, i-set up ang imprastraktura at ibigay ito sa mga developer para magamit. Ito ay napaka-cool!

Sa kabutihang palad, binibigyan ka ng AWS, GoogleCloud at iba pa ng isang taon ng libreng paggamit, kaya gamitin ang mga ito! Ang mga ito ay mura kung i-off mo ang mga ito kapag hindi ginagamit. I always wondered why I would need a remote server like gcloud, parang nahanap ko na sila.

Bilang isang lokal na virtual machine, maaari mong gamitin ang parehong Alpine, na aktibong ginagamit sa mga docker container. Buweno, o ilang iba pang magaan na pamamahagi upang gawing mas mabilis ang pag-boot ng makina.

Bottom line: maaari at dapat kang magpatakbo ng mga database at iba pang mga bagay sa imprastraktura sa mga malalayong server o sa virtualbox. Hindi ko kailangan ng docker para sa mga layuning ito.

Kaunti tungkol sa mga larawan at pamamahagi ng docker

Nagsulat na ako isang artikulo kung saan nais kong ipahiwatig na ang paggamit ng mga imahe ng docker ay hindi nagbibigay ng anumang garantiya. Ang mga larawan ng docker ay kailangan lamang upang lumikha ng isang docker container. Kung nag-a-upgrade ka sa isang docker na imahe, pagkatapos ay nag-a-upgrade ka upang gumamit ng mga docker container at gagamitin mo lang ang mga ito.

Nakita mo ba kahit saan kung saan inilalagay ng mga developer ng software ang kanilang mga produkto sa isang docker na imahe?
Ang resulta ng karamihan sa mga produkto ay binary file para sa isang partikular na platform; idinaragdag lamang ang mga ito sa docker image, na minana mula sa gustong platform. Naisip mo na ba kung bakit napakaraming katulad na larawan sa dockerhub? Ilagay ang nginx halimbawa, makikita mo ang 100500 mga larawan mula sa iba't ibang tao. Ang mga taong ito ay hindi bumuo ng nginx mismo, nagdagdag lamang sila ng opisyal na nginx sa kanilang docker na imahe at tinimplahan ito ng kanilang sariling mga config para sa kaginhawahan ng paglulunsad ng mga lalagyan.

Sa pangkalahatan, maaari mo lamang itong iimbak sa tgz, kung kailangan ng isang tao na patakbuhin ito sa docker, pagkatapos ay hayaan silang magdagdag ng tgz sa Dockerfile, magmana mula sa nais na kapaligiran at lumikha ng mga karagdagang bun na hindi nagbabago sa mismong application sa tgz. Ang sinumang gagawa ng imahe ng docker ay malalaman kung ano ang tgz at kung ano ang kailangan niya upang gumana. Ito ay kung paano ko ginagamit ang docker dito

Bottom line: Hindi ko kailangan ng docker registry, gagamit ako ng ilang uri ng S3 o imbakan lang ng file tulad ng google drive/dropbox

Docker sa CI

Lahat ng kumpanyang pinagtrabahuan ko ay magkatulad. Karaniwan silang nag-grocery. Iyon ay, mayroon silang isang application, isang stack ng teknolohiya (mabuti, marahil isang pares o tatlong mga programming language).

Ang mga kumpanyang ito ay gumagamit ng docker sa kanilang mga server kung saan tumatakbo ang proseso ng CI. Tanong: Bakit kailangan mong bumuo ng mga proyekto sa isang docker container sa iyong mga server? Bakit hindi na lang maghanda ng environment para sa build, halimbawa, magsulat ng Ansible playbook na mag-i-install ng mga kinakailangang bersyon ng nodejs, php, jdk, copy ssh keys, atbp. sa server kung saan magaganap ang build?

Ngayon naiintindihan ko na ito ay pagbaril sa aking sarili sa paa, dahil ang docker ay hindi nagdadala ng anumang kita sa kanyang paghihiwalay. Mga problemang nakatagpo ko sa CI sa docker:

• muli kailangan mo ng isang docker na imahe upang bumuo. kailangan mong maghanap ng isang imahe o magsulat ng iyong sariling dockerfile.
• 90% na kailangan mong ipasa ang ilang ssh key, sikretong data na hindi mo gustong isulat sa docker image.
• ang lalagyan ay nilikha at namatay, ang lahat ng mga cache ay nawala kasama nito. ang susunod na build ay muling ida-download ang lahat ng mga dependency ng proyekto, na nakakaubos ng oras at hindi epektibo, at ang oras ay pera.

Ang mga developer ay hindi gumagawa ng mga proyekto sa mga lalagyan ng docker (minsan ako ay isang tagahanga, talaga, naaawa ako sa aking sarili sa nakaraan xD). Sa java posible na magkaroon ng ilang mga bersyon at baguhin ang mga ito sa isang utos sa isa na kailangan mo ngayon. Ito ay pareho sa nodejs, mayroong nvm.

Pagbubuhos

Naniniwala ako na ang docker ay isang napakalakas at nababaluktot na tool, ito ang disbentaha nito (parang kakaiba, oo). Sa tulong nito, ang mga kumpanya ay madaling ma-hook dito at gamitin ito kung saan kinakailangan at hindi kinakailangan. Inilunsad ng mga developer ang kanilang mga lalagyan, ang ilan sa kanilang mga kapaligiran, pagkatapos ang lahat ng ito ay maayos na dumadaloy sa CI at produksyon. Ang DevOps team ay sumusulat ng ilang uri ng code para patakbuhin ang mga container na ito.

Gamitin lang ang docker sa ang pinakabago yugto sa iyong daloy ng trabaho, huwag i-drag ito sa proyekto sa simula. Hindi nito malulutas ang iyong mga problema sa negosyo. Ililipat lamang niya ang mga problema sa IBANG antas at mag-aalok ng kanyang sariling mga solusyon, gagawa ka ng dobleng trabaho.

Kapag kailangan ng docker: Nakarating ako sa konklusyon na ang docker ay napakahusay sa pag-optimize ng isang naibigay na proseso, ngunit hindi sa pagbuo ng pangunahing pag-andar

Kung magpasya ka pa ring gumamit ng docker, kung gayon:

• maging lubhang maingat
• huwag pilitin ang mga developer na gumamit ng docker
• I-localize ang paggamit nito sa isang lugar, huwag itong ikalat sa lahat ng Dockefile at docker-compose repository

PS:

• Kamakailan lang ay nakatagpo ako packer at sinasabi nila na ito ay gumagana nang mahusay sa Ansible at nagbibigay-daan sa iyong pag-isahin ang proseso ng pagbuo ng mga imahe (kabilang ang docker image)
• tungkol din sa docker, kawili-wiling artikulo

Salamat sa pagbabasa, nais kong maging malinaw ang iyong mga desisyon sa iyong mga gawain at produktibong araw ng trabaho!

Pinagmulan: www.habr.com