Моно-репозиторий тақырыбы бірнеше рет талқыланды және, әдетте, өте белсенді пікірталас тудырады. Жасау арқылы Git-тен Docker кескіндеріне қолданба кодын құру процесін жақсартуға арналған ашық бастапқы құрал ретінде (содан кейін оларды Kubernetes-ке жеткізу) біз қай таңдаудың жақсы екендігі туралы көп ойланбаймыз. Біз үшін әр түрлі пікірді жақтаушыларға қажеттінің барлығын қамтамасыз ету бірінші кезекте (әрине, бұл ақылға қайшы келмесе).
werf-тің жақында моно-репо қолдауы осының жақсы мысалы болып табылады. Алдымен, бұл қолдаудың werf-ті пайдаланумен қалай байланысты екенін және Docker тізілімінің оған қандай қатысы бар екенін анықтайық ...
Мәселелер
Осындай жағдайды елестетіп көрейік. Компанияда тәуелсіз жобалармен жұмыс істейтін көптеген әзірлеушілер тобы бар. Қолданбалардың көпшілігі Kubernetes жүйесінде жұмыс істейді және сондықтан контейнерге орналастырылады. Контейнерлерді, кескіндерді сақтау үшін сізге тізілім (тізілім) қажет. Мұндай тізілім ретінде компания Docker Hub қызметін бір тіркелгімен пайдаланады COMPANY. Көптеген бастапқы кодты сақтау жүйелеріне ұқсас, Docker Hub кірістірілген репозиторий иерархиясына рұқсат бермейді, сияқты COMPANY/PROJECT/IMAGE. Бұл жағдайда… әрбір жоба үшін жеке тіркелгі жасамай, монолитті емес қолданбаларды тізілімде осы шектеумен қалай сақтауға болады?
Мүмкін, сипатталған жағдай біреуге таныс шығар, бірақ жалпы қолданбаларды сақтауды ұйымдастыру мәселесін қарастырайық, яғни. жоғарыдағы мысалға және Docker хабына сілтемесіз.
Шешімдер
Қолданба болса монолитті, бір суретте келеді, содан кейін ешқандай сұрақтар болмайды және біз суреттерді жобаның контейнер тізіліміне сақтаймыз.
Қолданба бірнеше құрамдас ретінде ұсынылғанда, микросервис, содан кейін белгілі бір тәсіл қажет. Екі суреттен тұратын әдеттегі веб-қосымшаның мысалында: frontend и backend - ықтимал нұсқалар:
- Кескіндерді бөлек кірістірілген репозитарийлерде сақтаңыз:
- Барлығын бір репозиторийде сақтаңыз және тегтегі сурет атауын қарастырыңыз, мысалы, келесідей:
NB: Шындығында, әртүрлі репозиторийлерде сақтаудың тағы бір нұсқасы бар, PROJECT-frontend и PROJECT-backend, бірақ біз оны қолдаудың, ұйымдастырудың және пайдаланушылар арасындағы құқықтарды бөлудің күрделілігіне байланысты қарастырмаймыз.
werf қолдауы
Бастапқыда werf кірістірілген репозиторийлермен шектелді - бақытымызға орай, тізілімдердің көпшілігі бұл мүмкіндікті қолдайды. Нұсқасынан бастап , онда тізілімдермен жұмыс қосылды ұя салуға қолдау көрсетілмейді, және Docker Hub – солардың бірі. Осы сәттен бастап пайдаланушы қолданба кескіндерін сақтау жолын таңдауға ие болады.
Орындау опция бойынша қолжетімді --images-repo-mode=multirepo|monorepo (әдепкі multirepo, яғни. кірістірілген репозитарийлерде сақтау). Ол кескіндер тізілімде сақталатын үлгілерді анықтайды. Негізгі пәрмендерді пайдалану кезінде қажетті режимді таңдау жеткілікті, ал қалғанының бәрі өзгеріссіз қалады.
Өйткені көптеген werf опцияларын орнатуға болады ортаның айнымалылары, CI / CD жүйелерінде сақтау режимін әдетте бүкіл жоба үшін ғаламдық түрде орнату оңай. Мысалы, GitLab жағдайында жоба параметрлерінде орта айнымалы мәнін қосыңыз: Параметрлер -> CI / CD -> Айнымалылар: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Егер суреттерді жариялау және қосымшаларды шығару туралы айтатын болсақ (бұл процестер туралы тиісті құжаттама мақалаларында егжей-тегжейлі оқуға болады: и ), содан кейін режим кескінмен жұмыс істеуге болатын үлгіні ғана анықтайды.
Шайтан егжей-тегжейде
Жаңа сақтау әдісін қосу кезіндегі айырмашылық және негізгі қиындық тізілімді тазалау процесінде (werf қолдайтын тазалау мүмкіндіктерін қараңыз ).
Тазалау кезінде werf Kubernetes кластерлерінде пайдаланылатын кескіндерді, сондай-ақ пайдаланушы конфигурациялаған саясаттарды ескереді. Саясат тегтерді стратегияларға бөлуге негізделген. Қазіргі уақытта қолдау көрсетілетін стратегиялар:
- Git примитивтерімен байланыстырылған 3 стратегия, мысалы, тег, филиал және міндеттеме;
- Ерікті теңшелетін тегтерге арналған 1 стратегия.
Біз кескінді соңғы кескіннің жапсырмаларында жариялау кезінде тег стратегиясы туралы ақпаратты сақтаймыз. Мағынаның өзі деп аталатын нәрсе мета тег - Кейбір саясаттарды қолдану қажет. Мысалы, Git репозиторийінен тармақты немесе тегті жойған кезде, байланысты жою қисынды болады пайдаланылмаған саясаттарымыздың бір бөлігі қамтылған тізілімдегі суреттер.
Бір репозиторийде сақталған кезде (monorepo), сурет тегінде мета тегтен басқа суреттің атауын да сақтауға болады: PROJECT:frontend-META-TAG. Оларды бөлу үшін біз қандай да бір нақты бөлгішті енгізген жоқпыз, жай ғана жариялау кезінде соңғы кескіннің белгісіне қажетті мәнді қостық.
NB: Егер сіз werf бастапқы кодында сипатталғанның барлығын көргіңіз келсе, онда бастапқы нүкте болуы мүмкін .
Бұл мақалада біз проблемалар мен көзқарасымыздың негіздемесіне көбірек назар аудармаймыз: стратегияларды белгілеу, деректерді белгілерде сақтау және тұтастай алғанда жариялау процесі - мұның бәрі Дмитрий Столяровтың жақында жасаған баяндамасында егжей-тегжейлі сипатталған: ««.
қорытындысын
Кірістірілмеген тізілімдерге қолдаудың жоқтығы біз үшін немесе бізге белгілі werf пайдаланушылары үшін блоктаушы фактор болған жоқ - сіз әрқашан жеке кескін тізілімін көтере аласыз (немесе Google Cloud-та шартты контейнер тізіліміне ауыса аласыз) ... Дегенмен, Құралдың кеңірек DevOps қауымдастығына ыңғайлы болуы үшін мұндай шектеуді алып тастау қисынды болып көрінді. Оны жүзеге асыра отырып, біз контейнерлер тізілімін тазалау механизмін қайта өңдеуде негізгі қиындыққа тап болдық. Енді бәрі дайын, бұл біреу үшін оңайырақ болғанын түсіну жақсы, және біз (жобаның негізгі әзірлеушілері ретінде) бұл мүмкіндікті одан әрі қолдауда айтарлықтай қиындықтар болмайды.
Бізбен бірге болыңыз, жақын арада біз сізге басқа жаңалықтар туралы айтып береміз !
PS
Біздің блогта да оқыңыз:
- ««;
- ««.
Ақпарат көзі: www.habr.com