Stack Lifecycle Deployment
v3.6.2
OpenSource Solution qui définit et gère le cycle de vie complet des ressources utilisées et provisionnées dans un cloud!
Explorez les documents »
La SLD aide à accélérer le déploiement, la pondération et la fabrication de l'IAAC réutilisables, de générer des formes dynamiques et de maintenir différentes variables dans chaque environnement avec le même code. Avec SLD, vous pouvez planifier des déploiements d'infrastructure comme sa destruction, gérer les utilisateurs par des rôles et des piles séparées par escouade et environnement
Caractéristiques principales:
Le SLD est le moyen facile d'utiliser votre code en terre cuite!
Vous avez besoin de Docker et Docker-Compse ou Kind (recommandé).
Cloner le repo SLD
git clone https://github.com/D10S0VSkY-OSS/Stack-Lifecycle-Deployment.gitDéployer SLD en K8 avec Kind
cd Stack-Lifecycle-Deployment/play-with-sld/kubernetes
sh kplay.sh startRésultat:
Starting SLD for play
Creating cluster " kind " ...
✓ Ensuring node image (kindest/node:v1.20.2) ?
✓ Preparing nodes ? ?
✓ Writing configuration
✓ Starting control-plane ?️
✓ Installing CNI ?
✓ Installing StorageClass ?
✓ Joining worker nodes ?
Set kubectl context to " kind-kind "
You can now use your cluster with:
kubectl cluster-info --context kind-kindCréer un utilisateur init
sh kplay.sh initRésultat:
kind ok
docker ok
kubectl ok
jq ok
curl ok
init SLD
# ################################################
# Now, you can play with SLD ?️ #
# ################################################
API: http://localhost:5000/docs
DASHBOARD: http://localhost:5000/
---------------------------------------------
username: admin
password: Password08@
---------------------------------------------
Énumérer les endopintes
sh kplay.sh listRésultat:
kind ok
docker ok
kubectl ok
List endpoints
API: http://localhost:8000/docs
DASHBOARD: http://localhost:5000/Connexion au tableau de bord:
Cliquez sur le lien du tableau de bord:
Ajouter un compte cloud
Remplissez le formulaire avec les données requises. Dans notre exemple, nous utiliserons
Par défaut, les travailleurs fonctionnent en tant que squad1 et squad2 à des fins de jeu, mais vous pouvez le changer et l'échelle lorsque vous voulez
Lorsque vous ajoutez un compte à un fournisseur (AWS, GCP, Azure) une équipe est créée, vous devez créer un travailleur pour le nom de l'équipe créée, si vous ne le faites pas, le déploiement restera dans un état de lecture d'État "en attente"
Enfin ajouter:
Ajouter le module Terraform ou la pile
Prefixs pris en charge: aws_, gcp_, azure_
Vous pouvez transmettre l'utilisateur et le mot de passe sous le nom de https: // nom d'utilisateur: [email protected]/aws_vpc pour ssh Vous pouvez le passer comme secret dans le déploiement de l'utilisateur SLD
'*' = donne accès à tous, vous pouvez permettre l'accès à une ou plusieurs escouades séparées par des virgules: Squad1, Squad2
https://releases.hashicorp.com/terraform/
Déployez votre première pile !!!
Liste des piles pour le déploiement
Choisissez le déploiement
SLD générera un formulaire dynamique basé sur les variables de pile, remplira le formulaire et appuyez sur le bouton Déploier
Important! Attribuez la même équipe et l'environnement que nous avons créés précédemment lors de l'ajout du compte (voir Ajouter un compte Cloud)
Désormais, l'état de la tâche changera à mesure que le déploiement progresse.
Vous pouvez contrôler le cycle de vie de la mise en œuvre
Vous pouvez détruire, réimplémenter que SLD conservera les anciennes valeurs ou vous pouvez également modifier ces valeurs à volonté.
Et enfin, vous pouvez gérer le cycle de vie par programme, gérer la destruction / création de l'infrastructure, une bonne pratique pour le plan d'épargne !!! 
SLD utilise son propre backend distant, vous n'avez donc pas besoin de configurer aucun backend dans Terraform. L'exemple suivant montre une configuration backend
terraform {
backend "http" {
address = "http://remote-state:8080/terraform_state/aws_vpc-squad1-develop-vpc_core"
lock_address = "http://remote-state:8080/terraform_lock/aws_vpc-squad1-develop-vpc_core"
lock_method = "PUT"
unlock_address = "http://remote-state:8080/terraform_lock/aws_vpc-squad1-develop-vpc_core"
unlock_method = "DELETE"
}
}
À l'heure actuelle, SLD prend en charge MongoDB, S3 et le backend local (à des fins de test uniquement) pour configurer MongoDB en tant que backend, vous devez transmettre les variables suivantes sous forme de paramètres au service à distance:
# docker-compose.yaml
environment:
SLD_STORE: mongodb
SLD_MONGODB_URL: "mongodb:27017/"
MONGODB_USER: admin
MONGODB_PASSWD: admin
# k8s yaml
env:
- name: SLD_STORE
value: mongodb
- name: SLD_MONGODB_URL
value: "mongodb:27017/"
- name: MONGODB_USER
value: admin
- name: MONGODB_PASSWD
value: admin
Pour configurer S3, vous pouvez passer les clés d'accès et secrètes d'AWS, au cas où SLD s'exécute dans AWS, il est recommandé d'utiliser des rôles
env:
- name: SLD_STORE
value: "S3"
- name: SLD_BUCKET
value: "s3-sld-backend-cloud-tf-state"
- name: AWS_ACCESS_KEY
value: ""
- name: AWS_SECRET_ACCESS_KEY
value: ""
Pour Azure Env, vous avez besoin de définir le prochain env
env:
- name: SLD_STORE
value: azure
- name: AZURE_STORAGE_CONNECTION_STRING
value: "DefaultEndpointsProtocol=https;AccountName=<YOUR ACCOUNT>;AccountKey=<YOUR ACCESS KEY>;EndpointSuffix=core.windows.net"
Voir Azure-Storage-Configure-Connection-String
Pour le jeu de stockage Cloud Google:
SLD_STORE=gcp
export GOOGLE_APPLICATION_CREDENTIALS="/app/sld-gcp-credentials.json"
Importer la clé du compte de service Google à K8S Secret
kubectl create secret generic gcp-storage --from-file=~/Downloads/storage.json
Modifier SLD-Remote-state.yml Set GCP Storage Cloud Backend et Mount Secret:
apiVersion: apps/v1
kind: Deployment
metadata:
name: remote-state
labels:
name: remote-state
spec:
replicas: 1
selector:
matchLabels:
name: remote-state
template:
metadata:
labels:
name: remote-state
spec:
subdomain: primary
containers:
- name: remote-state
image: d10s0vsky/sld-remote-state:latest
volumeMounts:
- name: gcp
mountPath: "/app/gcp"
readOnly: true
env:
- name: SLD_STORE
value: gcp
- name: GOOGLE_APPLICATION_CREDENTIALS
value: "/app/gcp/storage.json"
resources:
limits:
memory: 600Mi
cpu: 1
requests:
memory: 300Mi
cpu: 500m
imagePullPolicy: Always
command: ["python3", "-m", "uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8080", "--workers", "1"]
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /
port: 8080
httpHeaders:
- name: status
value: healthy
initialDelaySeconds: 60
periodSeconds: 60
volumes:
- name: gcp
secret:
secretName: gcp-storage
Pour pouvoir utiliser les sorties d'autres piles, vous pouvez la configurer comme suit, la clé Alwys est la même comme "Nom de la tâche"
| nom de pile | compte de l'équipe | env | déploier le nom |
|---|---|---|---|
| aws_vpc | squad1 | développer | VPC_CORE |
data "terraform_remote_state" "vpc_core" {
backend = "http"
config = {
address = "http://remote-state:8080/terraform_state/aws_vpc-squad1-develop-vpc_core"
}
}
Exemple de test:
echo "data.terraform_remote_state.vpc_core.outputs"|terraform console
Les travailleurs de la SLD sont responsables de l'exécution du déploiement des infrastructures. Vous pouvez utiliser un ou plusieurs travailleurs pour chaque compte ou plusieurs comptes en même temps. Tout dépend du degré de parallélisme et de ségrégation que vous considérez
# Example k8s worker for account squad1, change this for each of your accounts
# Stack-Lifecycle-Deployment/play-with-sld/kubernetes/k8s/sld-worker-squad1.yml
# Add replicas for increment paralelism
# Add more squad accounts if you want to group accounts in the same worker:
# command: ["celery", "--app", "tasks.celery_worker", "worker", "--loglevel=info", "-c", "1", "-E", "-Q", "squad1,"another_squad_account"]
apiVersion: apps/v1
kind: Deployment
metadata:
name: stack-deploy-worker-squad1
labels:
name: stack-deploy-worker-squad1
spec:
replicas: 1
selector:
matchLabels:
name: stack-deploy-worker-squad1
template:
metadata:
labels:
name: stack-deploy-worker-squad1
spec:
subdomain: primary
containers:
- name: stack-deploy-worker-squad1
image: d10s0vsky/sld-api:latest
imagePullPolicy: Always
env:
- name: TF_WARN_OUTPUT_ERRORS
value: "1"
resources:
limits:
memory: 600Mi
cpu: 1
requests:
memory: 300Mi
cpu: 500m
command: ["celery", "--app", "tasks.celery_worker", "worker", "--loglevel=info", "-c", "1", "-E", "-Q", "squad1"]
# Example docker-compose worker for account squad1, change this for each of your accounts
# Stack-Lifecycle-Deployment/play-with-sld/docker/docker-compose.yml
worker:
image: d10s0vsky/sld-api:latest
entrypoint: ["celery", "--app", "tasks.celery_worker", "worker", "--loglevel=info", "-c", "1", "-E", "-Q", "squad1"]
environment:
BROKER_USER: admin
BROKER_PASSWD: admin
depends_on:
- rabbit
- redis
- db
- remote-state
SLD a trois rôles préconfigurés pour les utilisateurs pour gérer facilement cela.
| rôles | portée | description |
|---|---|---|
| yoda | mondial | Portée mondiale, peut voir toutes les escouades et sont admin complètes |
| darth_vader | une ou plusieurs équipes | Limiter la portée de l'équipe, peut voir les escouades assignées et vous êtes un gestionnaire complet de ces équipes uniquement |
| stormtroopher | une ou plusieurs équipes | Limite la gamme d'équipe, peut voir les escouades assignées et ne peut déploier que le déploiement assigné sur l'appartenance à l'équipe |
| R2-D2 | Tout, une ou plusieurs équipes | Ce rôle est uniquement pour l'identification et doit être associé aux précédents, son cas d'utilisation est destiné aux utilisateurs de bots qui accèdent à l'API |
Les contributions sont ce qui fait de la communauté open source un endroit si étonnant pour apprendre, inspirer et créer. Toutes les contributions que vous faites sont grandement appréciées .
git checkout -b feature/AmazingFeature )git commit -m 'Add some AmazingFeature' )git push origin feature/AmazingFeature ) Distribué sous la licence du MIT. Voir LICENSE pour plus d'informations.
Déploiement du cycle de vie de pile
