鶏が先か卵が先か? Infrastructure-as-Code の記事としては、かなり奇妙な始まりですね。
卵とは何ですか？
ほとんどの場合、Infrastructure-as-Code (IaC) はインフラストラクチャを表す宣言的な方法です。 その中で、ハードウェア部分からソフトウェア構成まで、取得したい状態を説明します。 したがって、IaC は次の目的で使用されます。
- リソースの提供。 これらは VM、S3、VPC などです。 作業用の基本的なツール: и .
- 。 主なツール: 、シェフなど。
すべてのコードは git リポジトリにあります。 そして遅かれ早かれ、チームリーダーはチーム内の物事を整理する必要があると判断します。 そして彼はリファクタリングをします。 そして、何らかの構造を作成します。 そして彼はそれが良いことだと分かるだろう。
すでに存在しているのもいいですね и -Terraform のプロバイダー (これはソフトウェア構成です)。 彼らの助けを借りて、チーム メンバー、CI / CD、git-flow などのプロジェクト全体を管理できます。
卵はどこから来たのですか？
ここで徐々に本題に近づいていきます。
まず、自分自身を含む他のリポジトリの構造を記述するリポジトリから始める必要があります。 そしてもちろん、GitOps 内では、変更が自動的に実装されるように CI を追加する必要があります。
Git がまだ作成されていない場合は?
- Git に保存するにはどうすればよいですか?
- CIをどうやって潰すか？
- IaC を使用して Gitlab をデプロイし、さらに Kubernetes にもデプロイしたらどうでしょうか?
- そしてKubernetesのGitLab Runnerも？
- そして、クラウドプロバイダーのKubernetesはどうでしょうか？
コードをアップロードする GitLab と、必要な GitLab の種類を説明するコードのどちらが先ですか?
卵入りチキン
«3 恐竜と一緒」 []
クラウドプロバイダーとして料理を作ってみよう .
TL; DR
すぐにXNUMXつのチームで行うことは可能ですか？
$ export MY_SELECTEL_TOKEN=<token>
$ curl https://gitlab.com/chicken-or-egg/mks/make/-/snippets/2002106/raw | bash成分：
- my.selectel.ru のアカウント。
- アカウントからのトークン。
- Kubernetes のスキル。
- ヘルムスキル;
- Terraform スキル。
- ヘルム チャート GitLab;
- ヘルム チャート GitLab Runner。
レシピ：
- パネルから MY_SELECTEL_TOKEN を取得します my.selectel.ru.
- アカウントからトークンを渡して、Kubernetes クラスターを作成します。
- 作成したクラスターからKUBECONFIGを取得します。
- Kubernetes に GitLab をインストールします。
- ユーザー用に生成された GitLab から GitLab トークンを取得します ルート.
- GitLab-token を使用して GitLab でプロジェクト構造を作成します。
- 既存のコードを GitLab にプッシュします。
- ???
- 利益！
ステップ1。 トークンはセクションで取得できます .
ステップ2。 2 ノードのクラスターを「ベイク」するために Terraform を準備します。 すべてに十分なリソースがあることが確実な場合は、自動クォータを有効にすることができます。
provider "selectel" {
token = var.my_selectel_token
}
variable "my_selectel_token" {}
variable "username" {}
variable "region" {}
resource "selectel_vpc_project_v2" "my-k8s" {
name = "my-k8s-cluster"
theme = {
color = "269926"
}
quotas {
resource_name = "compute_cores"
resource_quotas {
region = var.region
zone = "${var.region}a"
value = 16
}
}
quotas {
resource_name = "network_floatingips"
resource_quotas {
region = var.region
value = 1
}
}
quotas {
resource_name = "load_balancers"
resource_quotas {
region = var.region
value = 1
}
}
quotas {
resource_name = "compute_ram"
resource_quotas {
region = var.region
zone = "${var.region}a"
value = 32768
}
}
quotas {
resource_name = "volume_gigabytes_fast"
resource_quotas {
region = var.region
zone = "${var.region}a"
# (20 * 2) + 50 + (8 * 3 + 10)
value = 130
}
}
}
resource "selectel_mks_cluster_v1" "k8s-cluster" {
name = "k8s-cluster"
project_id = selectel_vpc_project_v2.my-k8s.id
region = var.region
kube_version = "1.17.9"
}
resource "selectel_mks_nodegroup_v1" "nodegroup_1" {
cluster_id = selectel_mks_cluster_v1.k8s-cluster.id
project_id = selectel_mks_cluster_v1.k8s-cluster.project_id
region = selectel_mks_cluster_v1.k8s-cluster.region
availability_zone = "${var.region}a"
nodes_count = 2
cpus = 8
ram_mb = 16384
volume_gb = 15
volume_type = "fast.${var.region}a"
labels = {
"project": "my",
}
}プロジェクトにユーザーを追加する:
resource "random_password" "my-k8s-user-pass" {
length = 16
special = true
override_special = "_%@"
}
resource "selectel_vpc_user_v2" "my-k8s-user" {
password = random_password.my-k8s-user-pass.result
name = var.username
enabled = true
}
resource "selectel_vpc_keypair_v2" "my-k8s-user-ssh" {
public_key = file("~/.ssh/id_rsa.pub")
user_id = selectel_vpc_user_v2.my-k8s-user.id
name = var.username
}
resource "selectel_vpc_role_v2" "my-k8s-role" {
project_id = selectel_vpc_project_v2.my-k8s.id
user_id = selectel_vpc_user_v2.my-k8s-user.id
}出力：
output "project_id" {
value = selectel_vpc_project_v2.my-k8s.id
}
output "k8s_id" {
value = selectel_mks_cluster_v1.k8s-cluster.id
}
output "user_name" {
value = selectel_vpc_user_v2.my-k8s-user.name
}
output "user_pass" {
value = selectel_vpc_user_v2.my-k8s-user.password
}私たちは以下を開始します:
$ env
TF_VAR_region=ru-3
TF_VAR_username=diamon
TF_VAR_my_selectel_token=<token>
terraform plan -out planfile
$ terraform apply -input=false -auto-approve planfile
ステップ3。 cubeconfig を取得します。
KUBECONFIG をプログラムでダウンロードするには、OpenStack からトークンを取得する必要があります。
openstack token issue -c id -f value > tokenそして、このトークンを使用して、マネージド Kubernetes Selectel API にリクエストを送信します。 k8s_id 配ります テラフォーム:
curl -XGET -H "x-auth-token: $(cat token)" "https://ru-3.mks.selcloud.ru/v1/clusters/$(cat k8s_id)/kubeconfig" -o kubeConfig.yamlcubeconfig にはパネルからもアクセスできます。
ステップ4。 クラスターが焼き上がり、それにアクセスできるようになったら、味に応じてヤムイモを上に追加できます。
私は次のように追加することを好みます。
- 名前空間、
- ストレージクラス、
- ポッドのセキュリティ ポリシーなど。
Selectel の場合は次から取得できます .
最初にゾーン内のクラスターを選択したため、 en-3aの場合、このゾーンのストレージ クラスも必要になります。
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: fast.ru-3a
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: cinder.csi.openstack.org
parameters:
type: fast.ru-3a
availability: ru-3a
allowVolumeExpansion: trueステップ5。 ロードバランサをインストールします。
この標準を多くの用途に使用します nginx-イングレス。 インストールに関する説明はすでにたくさんあるので、ここでは詳しく説明しません。
$ helm repo add nginx-stable https://helm.nginx.com/stable
$ helm upgrade nginx-ingress nginx-stable/nginx-ingress -n ingress --install -f ../internal/K8S-cluster/ingress/values.yml外部 IP を受信するまで約 3 ～ 4 分間待機します。
外部 IP を取得します。
ステップ6。 GitLabをインストールします。
$ helm repo add gitlab https://charts.gitlab.io
$ helm upgrade gitlab gitlab/gitlab -n gitlab --install -f gitlab/values.yml --set "global.hosts.domain=gitlab.$EXTERNAL_IP.nip.io"繰り返しますが、すべてのポッドが上昇するのを待ちます。
kubectl get po -n gitlab
NAME READY STATUS RESTARTS AGE
gitlab-gitaly-0 0/1 Pending 0 0s
gitlab-gitlab-exporter-88f6cc8c4-fl52d 0/1 Pending 0 0s
gitlab-gitlab-runner-6b6867c5cf-hd9dp 0/1 Pending 0 0s
gitlab-gitlab-shell-55cb6ccdb-h5g8x 0/1 Init:0/2 0 0s
gitlab-migrations.1-2cg6n 0/1 Pending 0 0s
gitlab-minio-6dd7d96ddb-zd9j6 0/1 Pending 0 0s
gitlab-minio-create-buckets.1-bncdp 0/1 Pending 0 0s
gitlab-postgresql-0 0/2 Pending 0 0s
gitlab-prometheus-server-6cfb57f575-v8k6j 0/2 Pending 0 0s
gitlab-redis-master-0 0/2 Pending 0 0s
gitlab-registry-6bd77b4b8c-pb9v9 0/1 Pending 0 0s
gitlab-registry-6bd77b4b8c-zgb6r 0/1 Init:0/2 0 0s
gitlab-shared-secrets.1-pc7-5jgq4 0/1 Completed 0 20s
gitlab-sidekiq-all-in-1-v1-54dbcf7f5f-qbq67 0/1 Pending 0 0s
gitlab-task-runner-6fd6857db7-9x567 0/1 Pending 0 0s
gitlab-webservice-d9d4fcff8-hp8wl 0/2 Pending 0 0s
Waiting gitlab
./wait_gitlab.sh ../internal/gitlab/gitlab/.pods
waiting for pod...
waiting for pod...
waiting for pod...ポッドが立ち上がりました:
ステップ7。 GitLab トークンを取得します。
まず、入力するパスワードを調べます。
kubectl get secret -n gitlab gitlab-gitlab-initial-root-password -o jsonpath='{.data.password}' | base64 --decode次に、ログインしてトークンを取得しましょう。
python3 get_gitlab_token.py root $GITLAB_PASSWORD http://gitlab.gitlab.$EXTERNAL_IP.nip.ioステップ8。 Gitlab プロバイダーを使用して、Git リポジトリを正しい階層に移動します。
cd ../internal/gitlab/hierarchy && terraform apply -input=false -auto-approve planfile残念ながら、terraform GitLab プロバイダーにはフローティング機能があります。 。 次に、tf.state を修正するには、競合するプロジェクトを手動で削除する必要があります。 次に、「$ make all」コマンドを再実行します。
ステップ9。 ローカルリポジトリをサーバーに転送します。
$ make push
[master (root-commit) b61d977] Initial commit
3 files changed, 46 insertions(+)
create mode 100644 .gitignore
create mode 100644 values.yml
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 770 bytes | 770.00 KiB/s, done.
Total 5 (delta 0), reused 0 (delta 0)完了：
まとめ
ローカル マシンからすべてを宣言的に管理できるようになりました。 ここで、これらすべてのタスクを CI に転送し、ボタンを押すだけにしたいと考えています。 これを行うには、ローカル状態 (Terraform 状態) を CI に転送する必要があります。 これを行う方法については、次のパートで説明します。
購読してください 新しい記事のリリースを見逃さないように！
出所： habr.com