Stack Lifecycle Deployment
v3.6.2
Solução OpenSource que define e gerencia o ciclo de vida completo dos recursos usados e provisionados em uma nuvem!
Explore os documentos »
O SLD ajuda a acelerar a implantação, ponderação e tornar reutilizável o IAAC, gerando formas dinâmicas e mantendo diferentes variáveis em cada ambiente com o mesmo código. Com o SLD, você pode agendar implantações de infraestrutura como sua destruição, gerenciar usuários por funções e separar pilhas por esquadrão e ambiente
Principais recursos:
SLD é a maneira mais fácil de usar seu código Terrafrom!
Você precisa do Docker e do Docker-Compse ou gentil (recomendado).
Clone o repo SLD
git clone https://github.com/D10S0VSkY-OSS/Stack-Lifecycle-Deployment.gitImplantar SLD em K8s com tipo
cd Stack-Lifecycle-Deployment/play-with-sld/kubernetes
sh kplay.sh startResultado:
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-kindCriar usuário init
sh kplay.sh initResultado:
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@
---------------------------------------------
Listar endoPints
sh kplay.sh listResultado:
kind ok
docker ok
kubectl ok
List endpoints
API: http://localhost:8000/docs
DASHBOARD: http://localhost:5000/Entrar no painel:
Clique no link do painel:
Adicione a conta da nuvem
Preencha o formulário com os dados necessários. Em nosso exemplo, usaremos
Por padrão, os trabalhadores estão sendo executados como Squad1 e Squad2 para fins de jogo, mas você pode alterá -lo e escalar quando quiser
Quando você adiciona uma conta a um provedor (AWS, GCP, Azure).
finalmente adicione:
Adicione o módulo ou pilha Terraform
Prefixos suportados: AWS_, gcp_, Azure_
Você pode passar o usuário e a senha como https: // nome de usuário: [email protected]/aws_vpc para ssh Você pode passá -lo como um segredo na implantação para o usuário SLD
'*' = dá acesso a todos, você pode permitir o acesso a um ou muitos esquadrões separados por vírgulas: esquadrão1, esquadrão2
https://releases.hashicorp.com/terraform/
Implante sua primeira pilha !!!
Listar pilhas para implantar
Escolha implantar
O SLD gerará um formulário dinâmico com base nas variáveis de pilha, preencha o formulário e pressione o botão de implantação
Importante! Atribua o mesmo esquadrão e ambiente que criamos anteriormente ao adicionar a conta (consulte a conta Add Cloud)
Agora, o status da tarefa mudará à medida que a implantação avança.
Você pode controlar o ciclo de vida da implementação
Você pode destruir, reimplementar que o SLD manterá os valores antigos ou também poderá editar esses valores à vontade.
E, finalmente, você pode gerenciar o ciclo de vida programaticamente, lidar com a destruição / criação da infraestrutura, uma boa prática para o plano de poupança !!! 
O SLD usa seu próprio back -end remoto, para que você não precise configurar nenhum back -end em Terraform. O exemplo a seguir mostra uma configuração de back -end
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"
}
}
No momento, o SLD suporta MongoDB, S3 e back-end local (apenas para fins de teste) para configurar o MongoDB como um back-end, você deve passar as seguintes variáveis como parâmetros para o serviço de estado remoto:
# 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
Para configurar o S3, você pode passar as chaves de acesso e secretas da AWS, caso o SLD esteja sendo executado na AWS, é recomendável usar funções
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: ""
Para o Azure Env, você precisa definir o próximo 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"
Consulte a corda de conexão-Configuração do Azure-Storage
Para o conjunto de armazenamento do Google Cloud:
SLD_STORE=gcp
export GOOGLE_APPLICATION_CREDENTIALS="/app/sld-gcp-credentials.json"
Importar a chave da conta do Serviço do Google para o segredo do K8S
kubectl create secret generic gcp-storage --from-file=~/Downloads/storage.json
Modificar SLD-Remote-state.yml Definir back-end de nuvem de armazenamento GCP e 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
Para poder usar as saídas de outras pilhas, você pode configurá -las da seguinte
| Nome da pilha | conta do esquadrão | Env | Nome da implantação |
|---|---|---|---|
| AWS_VPC | Esquadrão1 | desenvolver | VPC_CORE |
data "terraform_remote_state" "vpc_core" {
backend = "http"
config = {
address = "http://remote-state:8080/terraform_state/aws_vpc-squad1-develop-vpc_core"
}
}
Exemplo de teste:
echo "data.terraform_remote_state.vpc_core.outputs"|terraform console
Os trabalhadores da SLD são responsáveis por executar a implantação de infraestrutura. Você pode usar um ou mais trabalhadores para cada conta ou várias contas ao mesmo tempo. Tudo depende do grau de paralelismo e segregação que você considera
# 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
O SLD possui três funções pré -configuradas para os usuários gerenciarem isso facilmente.
| papéis | escopo | descrição |
|---|---|---|
| Yoda | global | Escopo global, pode ver todos os esquadrões e ser um administrador completo |
| darth_vader | um ou muitos esquadrões | Limite o escopo da equipe, pode ver os esquadrões atribuídos e você é um gerente completo apenas daqueles esquadrões |
| Stormtrooper | um ou muitos esquadrões | Limits Squads Range, pode ver esquadrões atribuídos e só pode implantar a implantação atribuída no esquadrão pertencente |
| R2-D2 | Todos, um ou muitos esquadrões | Essa função é apenas para identificação e deve estar associada aos anteriores, seu caso de uso é para usuários de bot que acessam a API |
As contribuições são o que torna a comunidade de código aberto um lugar tão incrível para aprender, inspirar e criar. Quaisquer contribuições que você faz são muito apreciadas .
git checkout -b feature/AmazingFeature )git commit -m 'Add some AmazingFeature' )git push origin feature/AmazingFeature ) Distribuído sob a licença do MIT. Consulte LICENSE para obter mais informações.
Implantação do ciclo de vida da pilha
