Stack Lifecycle Deployment
v3.6.2
¡Solución de OpenSource que define y administra el ciclo de vida completo de los recursos utilizados y aprovisionados en una nube!
Explore los documentos »
SLD ayuda a acelerar la implementación, ponderación y hacer que IAAC sea reutilizable, generando formas dinámicas y manteniendo diferentes variables en cada entorno con el mismo código. Con SLD puede programar implementaciones de infraestructura como su destrucción, administrar a los usuarios por roles y pilas separadas por escuadrón y entorno
Características principales:
¡SLD es la manera fácil de usar su código Terrafrom!
Necesita Docker y Docker-Compse o Kind (Recomended).
Clon el repositorio de SLD
git clone https://github.com/D10S0VSkY-OSS/Stack-Lifecycle-Deployment.gitImplementar SLD en K8 con amable
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-kindCrear usuario 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@
---------------------------------------------
Lista de endopints
sh kplay.sh listResultado:
kind ok
docker ok
kubectl ok
List endpoints
API: http://localhost:8000/docs
DASHBOARD: http://localhost:5000/Iniciar sesión en el tablero:
Haga clic en el enlace del tablero:
Agregar cuenta de nube
Complete el formulario con los datos requeridos. En nuestro ejemplo usaremos
Por defecto, los trabajadores se ejecutan como Squad1 y Squad2 para fines de juego, pero puede cambiarlo y escala cuando lo desee
Cuando agrega una cuenta a un proveedor (AWS, GCP, Azure) que se crea un escuadrón, debe crear un trabajador para el nombre del escuadrón creado, si no lo hace, el despliegue permanecerá en un estado "pendiente" que leen trabajadores
Finalmente agregar:
Agregar módulo o pila de terraform
Prefijos compatibles: AWS_, GCP_, Azure_
Puede aprobar el usuario y la contraseña como https: // username: contraseñ[email protected]/aws_vpc Para SSH, puede pasarlo como un secreto en la implementación al usuario SLD
'*' = da acceso a todos, puede permitir el acceso a uno o muchos escuadrones separados por comas: squad1, escuadrón2
https://releases.hashicorp.com/terraform/
Implementa tu primera pila !!!
Lista de pilas para la implementación
Elegir implementar
SLD generará un formulario dinámico basado en las variables de pila, complete el formulario y presione el botón Implementar
¡Importante! Asigne el mismo escuadrón y entorno que creamos anteriormente al agregar la cuenta (consulte Agregar cuenta de nube)
Ahora, el estado de la tarea cambiará a medida que avance la implementación.
Puede controlar el ciclo de vida de la implementación 
Puede destruir, reimplementar que SLD mantendrá los valores antiguos o también puede editar esos valores a voluntad. 
Y finalmente puede manejar el ciclo de vida mediante programación, manejar la destrucción / creación de la infraestructura, ¡una buena práctica para el plan de ahorro! 
SLD usa su propio backend remoto, por lo que no necesita configurar ningún backend en Terraform. El siguiente ejemplo muestra una configuración de 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"
}
}
En este momento, SLD admite MongoDB, S3 y Backend local (solo para fines de prueba) para configurar MongoDB como backend, debe pasar las siguientes variables como parámetros al servicio 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 S3, puede pasar el acceso y las claves secretas de AWS, en caso de que SLD se esté ejecutando en AWS, se recomienda usar roles
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 Azure Env, necesitas establecer el próximo envío
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"
Ver Azure-Storage-Configure-Connección de condición
Para el conjunto de almacenamiento en la nube de Google:
SLD_STORE=gcp
export GOOGLE_APPLICATION_CREDENTIALS="/app/sld-gcp-credentials.json"
Importar la clave de la cuenta de servicio de Google a K8s Secret
kubectl create secret generic gcp-storage --from-file=~/Downloads/storage.json
Modificar SLD-Remote-state.yml Establecer GCP Storage Cloud Backend and 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 las salidas de otras pilas, puede configurarlo de la siguiente manera, la clave Alwys es la misma como "Nombre de la tarea"
| nombre de pila | cuenta de escuadrón | envidia | Nombre de implementación |
|---|---|---|---|
| AWS_VPC | escuadrón | desarrollar | vpc_core |
data "terraform_remote_state" "vpc_core" {
backend = "http"
config = {
address = "http://remote-state:8080/terraform_state/aws_vpc-squad1-develop-vpc_core"
}
}
Ejemplo de prueba:
echo "data.terraform_remote_state.vpc_core.outputs"|terraform console
Los trabajadores en SLD son responsables de ejecutar la implementación de infraestructura. Puede usar uno o más trabajadores para cada cuenta o varias cuentas al mismo tiempo. Todo depende del grado de paralelismo y segregación que considere
# 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 tiene tres roles preconfigurados para que los usuarios lo administren fácilmente.
| roles | alcance | descripción |
|---|---|---|
| Yoda | global | Alcance global, puede ver todos los escuadrones y son administradores completos |
| Darth_vader | uno o muchos escuadrones | Limite el alcance del escuadrón, puede ver los escuadrones asignados y usted es un gerente completo de solo esos escuadrones |
| tormenta de asalto | uno o muchos escuadrones | Limits Squad Range, puede ver escuadrones asignados y solo puede implementar la implementación asignada en el escuadrón de pertenencia |
| R2-D2 | Todos, uno o muchos escuadrones | Este rol es solo para la identificación y debe estar asociado con los anteriores, su caso de uso es para los usuarios de BOT que acceden a la API |
Las contribuciones son lo que hace que la comunidad de código abierto sea un lugar tan increíble para aprender, inspirar y crear. Cualquier contribución que haga es muy apreciada .
git checkout -b feature/AmazingFeature )git commit -m 'Add some AmazingFeature' )git push origin feature/AmazingFeature ) Distribuido bajo la licencia MIT. Vea LICENSE para más información.
Implementación del ciclo de vida de pila
