Докер оюнчукпу же жокпу? Же дагы эле чынбы?

Баарына салам!

Мен чын эле темага түз өткүм келет, бирок менин окуям жөнүндө бир аз айтып берсем туура болот:

кирүү

Мен серверде бир беттик тиркемелерди, scala/java жана nodejs иштеп чыгуу боюнча тажрыйбасы бар программистмин.

Узак убакыт бою (албетте, бир-эки же үч жыл) мен Докер бул асмандан келген манна жана жалпысынан абдан сонун курал жана аны ар бир иштеп чыгуучу колдоно алышы керек деп ойлогом. Ошондон улам, ар бир иштеп чыгуучу өзүнүн жергиликтүү машинасында Docker орнотушу керек. Менин оюмча, ошол эле хх боюнча жарыяланган бош орундарды карап көрүңүз. Ар бир секундда докер жөнүндө сөз болот, эгер сиз ага ээ болсоңуз, бул сиздин атаандаштык артыкчылыгыңыз болот 😉

Жолдо баратып мен көптөгөн адамдарды жолуктурдум, алардын Докерге жана анын экосистемасына ар кандай мамилеси бар. Кээ бирөөлөр бул платформалар аралык иштөөгө кепилдик берген ыңгайлуу нерсе деп айтышты. Экинчилери эмне үчүн контейнерлерде чуркашарын жана андан кандай пайда болорун түшүнүшпөйт, үчүнчүсү такыр маани беришкен жок жана убара болбоду (код жазып, үйлөрүнө жөнөштү - мен аларга ичим ачышты, жол :)

Колдонуу себептери

Эмне үчүн мен докерди колдондум? Балким, төмөнкү себептерден улам:

• маалымат базасын ишке киргизүү, колдонмолордун 99% аларды колдонот
• фронтонду жайылтуу үчүн nginxти ишке киргизүү жана серверге проксисин коюу
• сиз тиркемени докердин сүрөтүндө топтой аласыз, менин колдонмом докер бар жерде иштейт, бөлүштүрүү маселеси дароо чечилет
• кызматтын ачылышы, сиз микросервистерди түзө аласыз, ар бир контейнер (жалпы тармакка туташкан) башка ат аркылуу оңой жете алат, абдан ыңгайлуу
• Контейнерди түзүү жана анда "ойноо" кызыктуу.

Мага докердин эмнеси жакпайт:

• Тиркеменим иштеши үчүн мага серверде Docker керек. Менин тиркемелерим jre же nodejsде иштесе жана алар үчүн чөйрө серверде мурунтан эле болсо, бул мага эмне үчүн керек?
• эгер мен (жеке) локалдык түрдө курулган сүрөтүмдү алыскы серверде иштетгим келсе, анда мага өзүмдүн докер репозиторийим керек, мага реестр бир жерде иштеши керек жана мен дагы https конфигурациялашым керек, анткени докер cli https аркылуу гана иштейт. Ох наалат... аркылуу жергиликтүү сүрөттү сактоо үчүн, албетте, параметрлери бар docker save жана жөн гана scp аркылуу сүрөттү жөнөтүү ... Бирок бул дененин көп кыймылы. Мындан тышкары, бул сиздин репозиторийиңиз пайда болгонго чейин "балдак" чечими сыяктуу көрүнөт
• docker-compose. Бул контейнерлерди иштетүү үчүн гана керек. Болду. Анын колунан башка эч нерсе келбейт. Docker-compose анын файлдарынын бир топ версиялары, өзүнүн синтаксиси бар. Канчалык декларативдүү болсо да, мен алардын документтерин окугум келбейт. Мага башка жерде кереги жок.
• командада иштегенде, көпчүлүк адамдар Докер файлын өтө кыйшык жазышат, анын кантип кэштелгенин түшүнүшпөйт, сүрөткө керектүү жана кереги жок нерселердин бардыгын кошуп, Dockerhub же жеке репозиторийде жок сүрөттөрдү мурастап, айрымдарын түзүшөт. docker-compose маалыматтар базасы бар файлдар жана эч нерсе сакталбайт. Ошол эле учурда, иштеп чыгуучулар Docker сонун экенин сыймыктануу менен айтышат, баары алар үчүн жергиликтүү иштейт жана HR вакансияда: "Биз Dockerди колдонобуз жана бизге ушундай иш тажрыйбасы бар талапкер керек" деп жазат.
• Мени дайыма Докерде баарын көтөрүү жөнүндө ойлор: postgresql, kafka, redis. Баары эле контейнерлерде иштебегени өкүнүчтүү, бардыгын конфигурациялоо жана иштетүү оңой эмес. Бул сатуучулар тарабынан эмес, үчүнчү тарап иштеп чыгуучулар тарабынан колдоого алынат. Айтмакчы, дароо суроо туулат: сатуучулар өз өнүмдөрүн Dockerде сактоо жөнүндө кабатырланбайт, эмне үчүн бул, балким, алар бир нерсе билишет?
• Контейнер маалыматтарынын туруктуулугу жөнүндө суроо ар дайым туулат. анан сиз ойлойсуз, мен жөн гана хост каталогун орнотушум керекпи же докердин көлөмүн түзсөмбү же азыр болгон маалымат контейнерин жасасамбы? deprecated? Эгерде мен каталогду орноткон болсом, анда контейнердеги колдонуучунун uid жана гид коддору контейнерди ишке киргизген колдонуучунун идентификаторуна дал келишине ынанышым керек, антпесе контейнер тарабынан түзүлгөн файлдар тамыр укуктары менен түзүлөт. Колдонсам volume анда маалыматтар жөн гана кээ бир түзүлөт /usr/* жана uid жана гид менен бир эле окуя болот биринчи учурда. Эгерде сиз үчүнчү тараптын компонентин ишке киргизип жатсаңыз, анда документтерди окуп чыгып, суроого жооп издешиңиз керек: "компонент кайсы контейнер каталогдоруна файлдарды жазат?"

Мага Докер менен көпкө чейин иштешкеним жакчу эмес баштапкы этапта: Мен контейнерлерди кантип ишке киргизүүнү, кандай сүрөттөрдөн баштоону түшүндүм, узун Docker буйруктарына лакап аттарды камтыган Makefiles жасадым. Мен докер-композитти жек көрдүм, анткени докер экосистемасындагы башка куралды үйрөнгүм келген жок. ЖАНА docker-compose up Айрыкча алар дагы эле ошол жерден жолукса, бул мени тынчсыздандырды build мурунтан эле чогултулган сүрөттөргө караганда конструкциялар. Мен чындап эле каалаган продуктуну натыйжалуу жана тез жасоо эле. Бирок мен докерди кантип колдонууну биле албадым.

Ansible менен тааныштыруу

Жакында (үч ай мурун) мен DevOps командасы менен иштегем, анын дээрлик ар бир мүчөсү Докерге терс көз карашта болчу. себептер боюнча:

• докер iptables эрежелерин сактайт (бирок сиз аны daemon.json ичинде өчүрө аласыз)
• докер ката жана биз аны өндүрүштө иштетпейбиз
• эгерде докер демону кыйраса, инфраструктурасы бар бардык контейнерлер ошого жараша бузулат
• докердин кереги жок
• Ansible жана виртуалдык машиналар бар болсо, эмне үчүн докер

Ошол эле жумушта мен дагы бир курал менен тааныштым - Ansible. Мен бул тууралуу бир жолу уктум, бирок өзүмдүн оюн китептеримди жазууга аракет кылган жокмун. Эми мен тапшырмаларымды жаза баштадым, анан менин көз карашым толугу менен өзгөрдү! Анткени мен түшүндүм: Ansible бир эле докер контейнерлерин иштетүү үчүн модулдары бар, сүрөттү түзүүдө, тармактарды ж.б. жана контейнерлерди жергиликтүү гана эмес, алыскы серверлерде да иштетсе болот! Менин кубанычымда чек жок - мен NORMAL куралын таап, Makefile жана докер-түзүүчү файлдарымды ыргытып жибердим, алар yaml тапшырмалары менен алмаштырылды. сыяктуу конструкцияларды колдонуу менен код кыскартылды loop, when, Etc.

Докер, маалымат базалары сыяктуу үчүнчү тараптын компоненттерин иштетүү үчүн

Мен жакында ssh туннелдери менен тааныштым. Алыскы сервердин портун локалдык портко "багыттоо" абдан оңой экени белгилүү болду. Алыскы сервер булуттагы машина же VirtualBoxта иштеген виртуалдык машина болушу мүмкүн. Эгерде менин кесиптешим же мага маалымат базасы (же башка үчүнчү тараптын компоненти) керек болсо, биз серверди ушул компонент менен жөн эле иштетип, сервердин кереги жок болгондо өчүрө алабыз. Порт багыттоо докер контейнеринде иштеген маалымат базасы сыяктуу эффект берет.

Бул буйрук менин жергиликтүү портумду postgresql иштеткен алыскы серверге багыттайт:

ssh -L 9000: localhost: 5432 [электрондук почта корголгон]

Алыскы серверди колдонуу команданы өнүктүрүү маселесин чечет. Мындай серверди бир эле учурда бир нече иштеп чыгуучулар колдонсо болот, алар postgresql конфигурациялай алышпайт, Docker жана башка татаал нерселерди түшүнүшөт. Алыскы серверде, белгилүү бир версияны орнотуу кыйын болсо, ошол эле маалымат базасын Dockerдин өзүнө орното аласыз. Бардык иштеп чыгуучуларга ssh мүмкүнчүлүгүн камсыз кылуу керек!

Мен жакында SSH туннелдери кадимки VPNдин чектелген функциясы экенин окудум! Сиз жөн гана OpenVPN же башка VPN ишке ашырууларын орнотуп, инфраструктураны орнотуп, аны иштеп чыгуучуларга колдонуу үчүн бере аласыз. Бул абдан сонун!

Бактыга жараша, AWS, GoogleCloud жана башкалар сизге бир жыл акысыз колдонуу мүмкүнчүлүгүн берет, андыктан аларды колдонуңуз! Колдонбогондо өчүрүп койсоңуз арзан болот. Мен ар дайым gcloud сыяктуу алыскы сервер эмне үчүн керек деп ойлончумун, мен аларды таптым окшойт.

Жергиликтүү виртуалдык машина катары сиз ошол эле Alpine колдоно аласыз, ал докер контейнерлеринде активдүү колдонулат. Ооба, же машинаны тезирээк жүктөө үчүн башка жеңил бөлүштүрүү.

Жыйынтык: сиз алыскы серверлерде же виртуалдык кутуда маалымат базаларын жана башка инфраструктуралык жакшы нерселерди иштете аласыз жана иштетишиңиз керек. Бул максаттар үчүн мага докердин кереги жок.

Докер сүрөттөрү жана бөлүштүрүү жөнүндө бир аз

Мен уже жазгам макала анда мен докер сүрөттөрүн колдонуу эч кандай кепилдик бербей турганын айткым келди. Докер сүрөттөрү докер контейнерин түзүү үчүн гана керек. Эгер сиз докер сүрөтүнө жаңыртып жатсаңыз, анда сиз докер контейнерлерин колдонуу үчүн жаңыртып жатасыз жана аларды гана колдоносуз.

Программалык камсыздоону иштеп чыгуучулар өз өнүмдөрүн докердин сүрөттөлүшүндө гана өткөргөн жерде көрдүңүз беле?
Көпчүлүк өнүмдөрдүн натыйжасы белгилүү бир платформа үчүн бинардык файлдар болуп саналат; алар жөн гана каалаган платформадан мураска алынган докер сүрөтүнө кошулат. Эмне үчүн dockerhubда окшош сүрөттөр көп экенин ойлонуп көрдүңүз беле? Мисалы, nginxти киргизиңиз, сиз ар кандай адамдардын 100500 XNUMX сүрөтүн көрөсүз. Бул адамдар nginxтин өзүн иштеп чыккан эмес, алар жөн гана докердин сүрөтүнө расмий nginxти кошуп, контейнерлерди ишке киргизүүнүн ыңгайлуулугу үчүн аны өздөрүнүн конфигурациялары менен татымалдашты.

Жалпысынан алганда, сиз аны жөн гана tgzде сактай аласыз, эгер кимдир бирөө аны докерде иштетүү керек болсо, анда аларга Dockerfileге tgz кошуп, каалаган чөйрөдөн мурастап, tgzде тиркеменин өзүн өзгөртпөй турган кошумча булочкаларды түзүүгө уруксат бериңиз. Докердин имиджин түзө турган ар бир адам tgz деген эмне экенин жана ал эмне иштеши керектигин билет. Мен докерди ушинтип колдоном бул жерде

Жыйынтык: Мага докер реестринин кереги жок, мен S3 түрүн же жөн гана google drive/dropbox сыяктуу файл сактагычты колдоном

CIдеги докер

Мен иштеген компаниялардын баары окшош. Алар, адатта, азык-түлүк. Башкача айтканда, аларда бир тиркеме, бир технология стек (жакшы, балким, бир нече же үч программалоо тили) бар.

Бул компаниялар CI процесси иштеген серверлеринде докерди колдонушат. Суроо - эмне үчүн серверлериңиздеги докер контейнеринде долбоорлорду куруу керек? Эмне үчүн жөн гана куруу үчүн чөйрөнү даярдап койбойсуз, мисалы, куруу боло турган серверге nodejs, php, jdk, ssh ачкычтарын көчүрүү ж.

Бул өзүмдүн бутума атып жатканын эми түшүндүм, анткени докер изоляциясы менен эч кандай пайда алып келбейт. Мен докерде CI менен жолуккан көйгөйлөр:

• кайра куруу үчүн докер сүрөтү керек. сиз сүрөт издеп же өзүңүздүн докер файлыңызды жазышыңыз керек.
• 90% кээ бир ssh баскычтарын, докер сүрөтүнө жазгыңыз келбеген жашыруун маалыматтарды жөнөтүшүңүз керек.
• контейнер түзүлөт жана өлөт, аны менен бирге бардык кэштер жоголот. кийинки куруу долбоордун бардык көз карандылыктарын кайра жүктөйт, бул көп убакытты талап кылат жана натыйжасыз, ал эми убакыт - акча.

Иштеп чыгуучулар докер контейнерлеринде долбоорлорду курушпайт (мен бир кезде ушундай күйөрман болчумун, чындыгында, өткөндө өзүмдү аяйм xD). Javaда бир нече версияга ээ болуп, аларды бир буйрук менен азыр керектүү версияга өзгөртүүгө болот. Бул nodejs да ушундай, nvm бар.

жыйынтыктоо

Мен докер абдан күчтүү жана ийкемдүү курал деп эсептейм, бул анын кемчилиги (кызык угулат, ооба). Анын жардамы менен компаниялар ага оңой эле байланып, аны керектүү жана керек эмес жерде колдоно алышат. Иштеп чыгуучулар контейнерлерин, кээ бир чөйрөлөрүн ишке киргизишет, андан кийин анын баары CI жана өндүрүшкө акырындык менен агып кетет. DevOps командасы бул контейнерлерди иштетүү үчүн кандайдыр бир код жазып жатат.

докерди гана колдонуңуз эң акыркы жумуш процессиңиздин этапта, башында аны долбоорго сүйрөп албаңыз. Бул сиздин бизнес көйгөйлөрүңүздү чечпейт. Ал көйгөйлөрдү БАШКА деңгээлге гана жылдырып, өзүнүн чечимдерин сунуштайт, сиз эки эселенген ишти жасайсыз.

Докер керек болгондо: Мен докер берилген процессти оптималдаштырууда абдан жакшы, бирок негизги функцияларды курууда эмес деген жыйынтыкка келдим.

Эгер сиз дагы эле докерди колдонууну чечсеңиз, анда:

• өтө сак болгула
• иштеп чыгуучуларды докерди колдонууга мажбурлабаңыз
• аны колдонууну бир жерде локалдаштыруу, аны бардык Dockfile жана докер-композиторлор боюнча жайылтпаңыз

PS:

• Мен жакында туш келдим таңгактоочу жана алар Ansible менен абдан жакшы иштейт деп айтышат жана сүрөттөрдү куруу процессин бириктирүүгө мүмкүндүк берет (анын ичинде докер сүрөтү)
• ошондой эле докер жөнүндө, кызыктуу макала

Окуганыңыз үчүн рахмат, ишиңизде ачык-айкын чечимдерди жана жемиштүү иш күндөрүн каалайм!

Source: www.habr.com