Кое е първо - кокошката или яйцето? Доста странно начало за статия за Infrastructure-as-Code, нали?
Какво е яйце?
Най-често Infrastructure-as-Code (IaC) е декларативен начин за представяне на инфраструктура. В него описваме състоянието, което искаме да постигнем, като започнем от хардуерната част и стигнем до софтуерната конфигурация. Следователно IaC се използва за:
Осигуряване на ресурси. Това са виртуални машини, S3, VPC и др. Основни инструменти за работа: тераформира и CloudFormation.
Всеки код е в git хранилища. И рано или късно ръководителят на екипа ще реши, че те трябва да бъдат приведени в ред. И той ще преработи. И ще създаде някаква структура. И той ще види, че това е добре.
Също така е добре, че вече съществува GitLab и GitHub-доставчик за Terraform (и това е софтуерна конфигурация). С тяхна помощ можете да управлявате целия проект: членове на екипа, CI/CD, git-flow и др.
Откъде се взе яйцето?
Така постепенно се доближаваме до основния въпрос.
На първо място, трябва да започнете с хранилище, което описва структурата на други хранилища, включително и вас. И разбира се, като част от GitOps, трябва да добавите CI, така че промените да се изпълняват автоматично.
Ако Git все още не е създаден?
Как да го съхраня в Git?
Как да инсталирам CI?
Ако разположим и Gitlab с помощта на IaC и дори в Kubernetes?
И GitLab Runner също в Kubernetes?
Какво ще кажете за Kubernetes в доставчика на облак?
Какво дойде първо: GitLab, където ще кача кода си, или кодът, който описва какъв тип GitLab ми трябва?
Вземете MY_SELECTEL_TOKEN от панела my.selectel.ru.
Създайте клъстер Kubernetes, като прехвърлите към него токен за акаунт.
Вземете KUBECONFIG от създадения клъстер.
Инсталирайте GitLab на Kubernetes.
Вземете GitLab-token от GitLab, създаден за потребителя корен.
Създайте структура на проект в GitLab с помощта на GitLab-token.
Изпратете съществуващ код към GitLab.
???
Печалба!
Стъпка 1. Токенът може да бъде получен в секцията API ключове.
Стъпка 2. Подготвяме нашата Terraform за „изпичане“ на клъстер от 2 възела. Ако сте сигурни, че имате достатъчно ресурси за всичко, тогава можете да активирате автоматичните квоти:
Стъпка 8. Привеждане на хранилищата на Git към правилната йерархия с помощта на доставчика на Gitlab.
cd ../internal/gitlab/hierarchy && terraform apply -input=false -auto-approve planfile
За съжаление доставчикът на terraform GitLab има плаващ буболечка. След това ще трябва да изтриете конфликтните проекти ръчно, за да бъде коригиран tf.state. След това изпълнете отново командата `$make all`
Стъпка 9. Прехвърляме локални хранилища на сървъра.
Постигнахме, че можем да управляваме всичко декларативно от нашата локална машина. Сега искам да прехвърля всички тези задачи в CI и просто да натискам бутони. За да направим това, трябва да прехвърлим нашите локални състояния (състояние на Terraform) към CI. Как да направите това е в следващата част.
Абонирайте се за нашите блогза да не пропуснете пускането на нови статии!