Despliegue

Esta página cubre poner Atlantis en funcionamiento en tu infraestructura.

Requisitos previos

Has creado access credentials para tu usuario de Atlantis
Has creado un webhook secret

Resumen de arquitectura

Runtime

Atlantis es una aplicación simple de Go. Recibe webhooks de tu host de Git y ejecuta comandos de Terraform localmente. Hay una Docker image oficial de Atlantis.

Enrutamiento

Atlantis y tu host de Git necesitan poder enrutar y comunicarse entre sí. Tu host de Git necesita poder enviar webhooks a Atlantis y Atlantis necesita poder hacer llamadas API a tu host de Git. Si estás usando un host de Git público como github.com, gitlab.com, gitea.com, bitbucket.org o dev.azure.com, entonces necesitarás exponer Atlantis a internet.

Si estás usando un host de Git privado como GitHub Enterprise, GitLab Enterprise, Gitea autohospedado o Bitbucket Server, entonces Atlantis necesita ser enrutable desde el host privado y Atlantis necesitará poder enrutar hacia el host privado.

Datos

Atlantis no tiene una base de datos externa. Atlantis almacena archivos de plan de Terraform en disco. Si Atlantis pierde esos datos entre un ciclo de plan y apply, entonces los usuarios tendrán que volver a ejecutar plan. Debido a esto, puede que quieras aprovisionar un disco persistente para Atlantis.

Despliegue

Elige tu tipo de despliegue:

Kubernetes Helm Chart
Kubernetes Manifests
Kubernetes Kustomize
OpenShift
AWS Fargate
Google Kubernetes Engine (GKE)
Docker
Roll Your Own

Kubernetes Helm Chart

Atlantis tiene un Helm chart oficial

Para instalar:

Agrega el repositorio del helm chart de runatlantis a helm

bash

helm repo add runatlantis https://runatlantis.github.io/helm-charts

Haz cd en un directorio donde vas a configurar tu Atlantis Helm chart

Crea un archivo values.yaml ejecutando

bash

helm inspect values runatlantis/atlantis > values.yaml

Edita values.yaml y agrega tus access credentials y webhook secret

yaml

# for example
github:
  user: foo
  token: bar
  secret: baz

Edita values.yaml y establece tu orgAllowlist (consulta Repo Allowlist para más información)
yaml
```
orgAllowlist: github.com/runatlantis/*
```
Nota: Para la versión del helm chart < 4.0.2, debe usarse orgWhitelist en su lugar.
Configura cualquier otra variable (consulta Atlantis Helm Chart: Customization para la documentación)

Ejecuta

helm install atlantis runatlantis/atlantis -f values.yaml

Si estás usando helm v2, ejecuta:

helm install -f values.yaml runatlantis/atlantis

¡Atlantis debería estar en funcionamiento en minutos! Consulta Next Steps para qué hacer después.

Kubernetes Manifests

Si te gustaría usar un manifest de Kubernetes sin procesar, ofrecemos ya sea un Deployment o un Statefulset con almacenamiento persistente.

Se recomienda StatefulSet porque Atlantis almacena sus datos en disco y por lo tanto si tu Pod muere o actualizas Atlantis, no perderás los plans que no se han aplicado. Si sí pierdes esos datos, solo necesitas ejecutar atlantis plan de nuevo, así que no es el fin del mundo.

Independientemente de si eliges un Deployment o StatefulSet, primero crea un Secret con el webhook secret y el access token:

bash

echo -n "yourtoken" > token
echo -n "yoursecret" > webhook-secret
kubectl create secret generic atlantis-vcs --from-file=token --from-file=webhook-secret

A continuación, edita los manifests de abajo de la siguiente manera:

Reemplaza <VERSION> en image: ghcr.io/runatlantis/atlantis:<VERSION> con la versión más reciente de GitHub: Atlantis latest release.
- NOTA: Nunca querrás ejecutar con :latest porque si tu Pod se mueve a un nodo nuevo, Kubernetes extraerá la imagen más reciente y podrías terminar actualizando Atlantis por accidente.
Reemplaza value: github.com/yourorg/* bajo name: ATLANTIS_REPO_ALLOWLIST con el patrón de allowlist para tus repos de Terraform. Consulta --repo-allowlist para más detalles.
Si estás usando GitHub:
1. Reemplaza <YOUR_GITHUB_USER> con el nombre de usuario de tu usuario de Atlantis de GitHub sin el @.
2. Elimina todas las variables de entorno ATLANTIS_GITLAB_*, ATLANTIS_GITEA_*, ATLANTIS_BITBUCKET_* y ATLANTIS_AZUREDEVOPS_*.
Si estás usando GitLab:
1. Reemplaza <YOUR_GITLAB_USER> con el nombre de usuario de tu usuario de Atlantis de GitLab sin el @.
2. Elimina todas las variables de entorno ATLANTIS_GH_*, ATLANTIS_GITEA_*, ATLANTIS_BITBUCKET_* y ATLANTIS_AZUREDEVOPS_*.
Si estás usando Gitea:
1. Reemplaza <YOUR_GITEA_USER> con el nombre de usuario de tu usuario de Atlantis de Gitea sin el @.
2. Elimina todas las variables de entorno ATLANTIS_GH_*, ATLANTIS_GITLAB_*, ATLANTIS_BITBUCKET_* y ATLANTIS_AZUREDEVOPS_*.
Si estás usando Bitbucket:
1. Reemplaza <YOUR_BITBUCKET_USER> con el nombre de usuario de tu usuario de Atlantis de Bitbucket sin el @.
2. Elimina todas las variables de entorno ATLANTIS_GH_*, ATLANTIS_GITLAB_*, ATLANTIS_GITEA_* y ATLANTIS_AZUREDEVOPS_*.
Si estás usando Azure DevOps:
1. Reemplaza <YOUR_AZUREDEVOPS_USER> con el nombre de usuario de tu usuario de Atlantis de Azure DevOps sin el @.
2. Elimina todas las variables de entorno ATLANTIS_GH_*, ATLANTIS_GITLAB_*, ATLANTIS_GITEA_* y ATLANTIS_BITBUCKET_*.

Manifest de StatefulSet

Mostrar...

yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: atlantis
spec:
  serviceName: atlantis
  replicas: 1
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      partition: 0
  selector:
    matchLabels:
      app.kubernetes.io/name: atlantis
  template:
    metadata:
      labels:
        app.kubernetes.io/name: atlantis
    spec:
      securityContext:
        fsGroup: 1000 # Atlantis group (1000) read/write access to volumes.
      containers:
      - name: atlantis
        image: ghcr.io/runatlantis/atlantis:v<VERSION> # 1. Replace <VERSION> with the most recent release.
        env:
        - name: ATLANTIS_REPO_ALLOWLIST
          value: github.com/yourorg/* # 2. Replace this with your own repo allowlist.

        ### GitHub Config ###
        - name: ATLANTIS_GH_USER
          value: <YOUR_GITHUB_USER> # 3i. If you're using GitHub replace <YOUR_GITHUB_USER> with the username of your Atlantis GitHub user without the `@`.
        - name: ATLANTIS_GH_TOKEN
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: token
        - name: ATLANTIS_GH_WEBHOOK_SECRET
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: webhook-secret
        ### End GitHub Config ###

        ### GitLab Config ###
        - name: ATLANTIS_GITLAB_USER
          value: <YOUR_GITLAB_USER> # 4i. If you're using GitLab replace <YOUR_GITLAB_USER> with the username of your Atlantis GitLab user without the `@`.
        - name: ATLANTIS_GITLAB_TOKEN
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: token
        - name: ATLANTIS_GITLAB_WEBHOOK_SECRET
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: webhook-secret
        ### End GitLab Config ###

        ### Gitea Config ###
        - name: ATLANTIS_GITEA_USER
          value: <YOUR_GITEA_USER> # 4i. If you're using Gitea replace <YOUR_GITEA_USER> with the username of your Atlantis Gitea user without the `@`.
        - name: ATLANTIS_GITEA_TOKEN
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: token
        - name: ATLANTIS_GITEA_WEBHOOK_SECRET
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: webhook-secret
        ### End Gitea Config ###

        ### Bitbucket Config ###
        - name: ATLANTIS_BITBUCKET_USER
          value: <YOUR_BITBUCKET_USER> # 5i. If you're using Bitbucket replace <YOUR_BITBUCKET_USER> with the username of your Atlantis Bitbucket user without the `@`.
        - name: ATLANTIS_BITBUCKET_TOKEN
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: token
        - name: ATLANTIS_BITBUCKET_WEBHOOK_SECRET
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: webhook-secret
        ### End Bitbucket Config ###

        ### Azure DevOps Config ###
        - name: ATLANTIS_AZUREDEVOPS_USER
          value: <YOUR_AZUREDEVOPS_USER> # 6i. If you're using Azure DevOps replace <YOUR_AZUREDEVOPS_USER> with the username of your Atlantis Azure DevOps user without the `@`.
        - name: ATLANTIS_AZUREDEVOPS_TOKEN
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: token
        - name: ATLANTIS_AZUREDEVOPS_WEBHOOK_USER
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: basic-user
        - name: ATLANTIS_AZUREDEVOPS_WEBHOOK_PASSWORD
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: basic-password
        ### End Azure DevOps Config ###

        - name: ATLANTIS_DATA_DIR
          value: /atlantis
        - name: ATLANTIS_PORT
          value: "4141" # Kubernetes sets an ATLANTIS_PORT variable so we need to override.
        volumeMounts:
        - name: atlantis-data
          mountPath: /atlantis
        ports:
        - name: atlantis
          containerPort: 4141
        resources:
          requests:
            memory: 256Mi
            cpu: 100m
          limits:
            memory: 256Mi
            cpu: 100m
        livenessProbe:
          # We only need to check every 60s since Atlantis is not a
          # high-throughput service.
          periodSeconds: 60
          httpGet:
            path: /healthz
            port: 4141
            # If using https, change this to HTTPS
            scheme: HTTP
        readinessProbe:
          periodSeconds: 60
          httpGet:
            path: /healthz
            port: 4141
            # If using https, change this to HTTPS
            scheme: HTTP
  volumeClaimTemplates:
  - metadata:
      name: atlantis-data
    spec:
      accessModes: ["ReadWriteOnce"] # Volume should not be shared by multiple nodes.
      resources:
        requests:
          # The biggest thing Atlantis stores is the Git repo when it checks it out.
          # It deletes the repo after the pull request is merged.
          storage: 5Gi
---
apiVersion: v1
kind: Service
metadata:
  name: atlantis
spec:
  type: ClusterIP
  ports:
  - name: atlantis
    port: 80
    targetPort: 4141
  selector:
    app.kubernetes.io/name: atlantis

Manifest de Deployment

Mostrar...

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: atlantis
  labels:
    app.kubernetes.io/name: atlantis
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: atlantis
  template:
    metadata:
      labels:
        app.kubernetes.io/name: atlantis
    spec:
      containers:
      - name: atlantis
        image: ghcr.io/runatlantis/atlantis:v<VERSION> # 1. Replace <VERSION> with the most recent release.
        env:
        - name: ATLANTIS_REPO_ALLOWLIST
          value: github.com/yourorg/* # 2. Replace this with your own repo allowlist.

        ### GitHub Config ###
        - name: ATLANTIS_GH_USER
          value: <YOUR_GITHUB_USER> # 3i. If you're using GitHub replace <YOUR_GITHUB_USER> with the username of your Atlantis GitHub user without the `@`.
        - name: ATLANTIS_GH_TOKEN
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: token
        - name: ATLANTIS_GH_WEBHOOK_SECRET
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: webhook-secret
        ### End GitHub Config ###

        ### GitLab Config ###
        - name: ATLANTIS_GITLAB_USER
          value: <YOUR_GITLAB_USER> # 4i. If you're using GitLab replace <YOUR_GITLAB_USER> with the username of your Atlantis GitLab user without the `@`.
        - name: ATLANTIS_GITLAB_TOKEN
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: token
        - name: ATLANTIS_GITLAB_WEBHOOK_SECRET
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: webhook-secret
        ### End GitLab Config ###

        ### Gitea Config ###
        - name: ATLANTIS_GITEA_USER
          value: <YOUR_GITEA_USER> # 4i. If you're using Gitea replace <YOUR_GITEA_USER> with the username of your Atlantis Gitea user without the `@`.
        - name: ATLANTIS_GITEA_TOKEN
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: token
        - name: ATLANTIS_GITEA_WEBHOOK_SECRET
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: webhook-secret
        ### End Gitea Config ###

        ### Bitbucket Config ###
        - name: ATLANTIS_BITBUCKET_USER
          value: <YOUR_BITBUCKET_USER> # 5i. If you're using Bitbucket replace <YOUR_BITBUCKET_USER> with the username of your Atlantis Bitbucket user without the `@`.
        - name: ATLANTIS_BITBUCKET_TOKEN
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: token
        ### End Bitbucket Config ###

        ### Azure DevOps Config ###
        - name: ATLANTIS_AZUREDEVOPS_USER
          value: <YOUR_AZUREDEVOPS_USER> # 6i. If you're using Azure DevOps replace <YOUR_AZUREDEVOPS_USER> with the username of your Atlantis Azure DevOps user without the `@`.
        - name: ATLANTIS_AZUREDEVOPS_TOKEN
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: token
        - name: ATLANTIS_AZUREDEVOPS_WEBHOOK_USER
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: basic-user
        - name: ATLANTIS_AZUREDEVOPS_WEBHOOK_PASSWORD
          valueFrom:
            secretKeyRef:
              name: atlantis-vcs
              key: basic-password
        ### End Azure DevOps Config ###

        - name: ATLANTIS_PORT
          value: "4141" # Kubernetes sets an ATLANTIS_PORT variable so we need to override.
        ports:
        - name: atlantis
          containerPort: 4141
        resources:
          requests:
            memory: 256Mi
            cpu: 100m
          limits:
            memory: 256Mi
            cpu: 100m
        livenessProbe:
          # We only need to check every 60s since Atlantis is not a
          # high-throughput service.
          periodSeconds: 60
          httpGet:
            path: /healthz
            port: 4141
            # If using https, change this to HTTPS
            scheme: HTTP
        readinessProbe:
          periodSeconds: 60
          httpGet:
            path: /healthz
            port: 4141
            # If using https, change this to HTTPS
            scheme: HTTP
---
apiVersion: v1
kind: Service
metadata:
  name: atlantis
spec:
  type: ClusterIP
  ports:
  - name: atlantis
    port: 80
    targetPort: 4141
  selector:
    app.kubernetes.io/name: atlantis

Enrutamiento y SSL

Los manifests anteriores crean un Service de Kubernetes de tipo type: ClusterIP que no es accesible fuera de tu clúster. Dependiendo de cómo estés haciendo el enrutamiento hacia Kubernetes, puede que quieras usar un Service de tipo type: LoadBalancer para que Atlantis sea accesible para GitHub/GitLab y tus usuarios internos.

Si quieres agregar SSL, puedes usar algo como cert-manager para generar certificados SSL y montarlos en el Pod. Luego establece las variables de entorno ATLANTIS_SSL_CERT_FILE e ATLANTIS_SSL_KEY_FILE para habilitar SSL. También podrías configurar SSL en tu LoadBalancer.

¡Ya terminaste! Consulta Next Steps para qué hacer después.

Kubernetes Kustomize

Se proporciona un archivo kustomization.yaml en el directorio kustomize/, por lo que puedes usar este repositorio como una base remota para desplegar Atlantis con Kustomize.

Necesitarás proporcionar un secret (con el nombre predeterminado atlantis-vcs) para configurar Atlantis con access credentials para tus repositorios remotos.

Ejemplo:

yaml

bases:
- github.com/runatlantis/atlantis//kustomize

resources:
- secrets.yaml

Importante: Debes asegurarte de aplicar parches a los manifests proporcionados con las variables de entorno correctas para tu instalación. Puedes crear parches inline desde tu archivo kustomization.yaml como se muestra abajo:

yaml

patchesStrategicMerge:
- |-
  apiVersion: apps/v1
  kind: StatefulSet
  metadata:
    name: atlantis
  spec:
    template:
      spec:
        ...

Requerido

yaml

...
 containers:
  - name: atlantis
    env:
      - name: ATLANTIS_REPO_ALLOWLIST
        value: github.com/yourorg/* # 2. Replace this with your own repo allowlist.

GitLab

yaml

...
containers:
- name: atlantis
  env:
    - name: ATLANTIS_GITLAB_USER
      value: <YOUR_GITLAB_USER> # 4i. If you're using GitLab replace <YOUR_GITLAB_USER> with the username of your Atlantis GitLab user without the `@`.
    - name: ATLANTIS_GITLAB_TOKEN
      valueFrom:
        secretKeyRef:
          name: atlantis-vcs
          key: token
    - name: ATLANTIS_GITLAB_WEBHOOK_SECRET
      valueFrom:
        secretKeyRef:
          name: atlantis-vcs
          key: webhook-secret

Gitea

yaml

containers:
- name: atlantis
  env:
    - name: ATLANTIS_GITEA_USER
      value: <YOUR_GITEA_USER> # 4i. If you're using Gitea replace <YOUR_GITEA_USER> with the username of your Atlantis Gitea user without the `@`.
    - name: ATLANTIS_GITEA_TOKEN
      valueFrom:
        secretKeyRef:
          name: atlantis-vcs
          key: token
    - name: ATLANTIS_GITEA_WEBHOOK_SECRET
      valueFrom:
        secretKeyRef:
          name: atlantis-vcs
          key: webhook-secret

GitHub

yaml

...
containers:
- name: atlantis
  env:
    - name: ATLANTIS_GH_USER
      value: <YOUR_GITHUB_USER> # 3i. If you're using GitHub replace <YOUR_GITHUB_USER> with the username of your Atlantis GitHub user without the `@`.
    - name: ATLANTIS_GH_TOKEN
      valueFrom:
        secretKeyRef:
          name: atlantis-vcs
          key: token
    - name: ATLANTIS_GH_WEBHOOK_SECRET
      valueFrom:
        secretKeyRef:
          name: atlantis-vcs
          key: webhook-secret

BitBucket

yaml

...
containers:
- name: atlantis
  env:
    - name: ATLANTIS_BITBUCKET_USER
      value: <YOUR_BITBUCKET_USER> # 5i. If you're using Bitbucket replace <YOUR_BITBUCKET_USER> with the username of your Atlantis Bitbucket user without the `@`.
    - name: ATLANTIS_BITBUCKET_TOKEN
      valueFrom:
        secretKeyRef:
          name: atlantis-vcs
          key: token

OpenShift

El Helm chart y los manifests de Kubernetes de arriba son compatibles con OpenShift, sin embargo necesitas ejecutar con una variable de entorno adicional: HOME=/home/atlantis. Esto es requerido porque OpenShift ejecuta imágenes de Docker con ID de usuario aleatorios que usan / como su directorio home.

AWS Fargate

Si te gustaría ejecutar Atlantis en AWS Fargate revisa el módulo de Atlantis en el Terraform Module Registry y luego consulta Next Steps.

Google Kubernetes Engine (GKE)

Puedes ejecutar Atlantis en GKE usando el Helm chart o los manifests.

También hay un conjunto de configuraciones completas de Terraform que crean un clúster de GKE, Cloud Storage Backend y certificados TLS: sethvargo atlantis-on-gke.

Una vez que termines, consulta Next Steps.

Google Compute Engine (GCE)

Atlantis puede ejecutarse en Google Compute Engine usando un módulo de Terraform que lo despliega como un contenedor Docker en una instancia administrada de Compute Engine.

Este Terraform module incluye la creación de un balanceador de carga de Cloud, una VM basada en Container-Optimized OS, un disco de datos persistente y un grupo de instancias administrado.

Después de que esté desplegado, consulta Next Steps.

Docker

Atlantis tiene una Docker image oficial: ghcr.io/runatlantis/atlantis.

Variantes de imagen

Cada release se publica en cuatro variantes. El tag sin sufijo (por ejemplo v0.47.1 o latest) es la imagen Alpine.

Sufijo de tag	Base	Terraform y OpenTofu incluidos
`-alpine`	Alpine	sí
`-debian`	Debian	sí
`-alpine-slim`	Alpine	no
`-debian-slim`	Debian	no

Las imágenes completas incluyen las últimas pocas releases menores de Terraform y la release actual de OpenTofu, y terraform en PATH apunta a la más nueva de ellas.

Las imágenes slim se entregan sin ninguno de los dos binarios, por lo que los escáneres de vulnerabilidades no informan avisos contra versiones de Terraform u OpenTofu que quizá ni siquiera uses. Todo lo demás (conftest, git-lfs, git, curl, dumb-init) es igual que en la imagen completa. Atlantis descarga la versión de Terraform que necesita en el primer uso, por lo que a la imagen slim se le debe indicar cuál es esa versión:

Establece --default-tf-version como un flag, como ATLANTIS_DEFAULT_TF_VERSION, o en el archivo de configuración del servidor. Sin eso, el servidor se niega a iniciar con terraform not found in $PATH. La imagen slim deliberadamente no establece ningún valor predeterminado propio, porque una variable de entorno incorporada en la imagen tendría precedencia sobre una versión fijada en tu archivo de configuración.
terraform_version por proyecto en atlantis.yaml e --tf-download-url funcionan como siempre.
Para OpenTofu, establece ATLANTIS_TF_DISTRIBUTION=opentofu y proporciona una versión de OpenTofu como predeterminada.
Si las descargas salientes no están permitidas desde tu host de Atlantis (--tf-download=false), monta o copia en la imagen los binarios que necesitas en su lugar. Consulta Customization abajo.

Customization

Si necesitas modificar la imagen Docker que proporcionamos, por ejemplo para agregar el binario de terragrunt, puedes hacer algo como esto:

Crea un archivo docker personalizado

dockerfile

FROM ghcr.io/runatlantis/atlantis:{latest version}

# copy a terraform binary of the version you need
USER root
COPY terragrunt /usr/local/bin/terragrunt
USER atlantis

A partir de la versión 0.26.0, la imagen de Atlantis se ha actualizado para ejecutarse bajo el usuario atlantis, reemplazando la configuración anterior del usuario root. Este cambio requiere ajustes en las definiciones de contenedor y scripts existentes para adaptarse a la nueva configuración de usuario. En escenarios donde se requieran paquetes adicionales de otras imágenes, los usuarios pueden cambiar temporalmente al usuario root insertando USER root en el Dockerfile. Después de la instalación de los paquetes necesarios, es aconsejable volver al usuario atlantis para iniciar el servicio de Atlantis. Además, el directorio /docker-entrypoint.d/ ofrece una opción flexible para introducir scripts extra que se ejecuten antes del inicio del servidor Atlantis. Esta característica es particularmente beneficiosa para usuarios que buscan personalizar su instancia de Atlantis sin la necesidad de desarrollar un pipeline dedicado. Aviso importante: Hay una actualización crítica con respecto al directorio de datos en Atlantis. En las versiones anteriores a 0.26.0, el directorio estaba configurado para ser accesible por el usuario root. Sin embargo, con la transición al usuario atlantis en las versiones más nuevas, es imperativo actualizar los permisos del directorio en tu despliegue actual al actualizar a una versión posterior a 0.26.0. Este paso asegura acceso y funcionalidad sin problemas para el usuario atlantis.

Construye tu imagen Docker

bash

docker build -t {YOUR_DOCKER_ORG}/atlantis-custom .

Ejecuta tu imagen

bash

docker run {YOUR_DOCKER_ORG}/atlantis-custom server --gh-user=GITHUB_USERNAME --gh-token=GITHUB_TOKEN

Microsoft Azure

El Kubernetes Helm Chart estándar debería funcionar bien en Azure Kubernetes Service.

Otra opción es Azure Container Instances. Consulta el repo de este miembro de la comunidad o el Terraform module nuevo y más actualizado para scripts de instalación y más información sobre ejecutar Atlantis en ACI.

Nota sobre el despliegue en ACI: Debido a un bug en releases anteriores de Docker, se requiere Docker v23.0.0 o posterior para un despliegue sencillo. Como alternativa, la imagen Docker de Atlantis puede subirse a un registro privado como ACR y luego usarse.

Roll Your Own

Si quieres hacer tu propia instalación de Atlantis, puedes obtener el binario atlantis desde GitHub o usar la Docker image oficial.

Comando de inicio

Los flags exactos para atlantis server dependen de tu host de Git:

GitHub

bash

atlantis server \
--atlantis-url="$URL" \
--gh-user="$USERNAME" \
--gh-token="$TOKEN" \
--gh-webhook-secret="$SECRET" \
--repo-allowlist="$REPO_ALLOWLIST"

GitHub Enterprise

bash

HOSTNAME=YOUR_GITHUB_ENTERPRISE_HOSTNAME # ex. github.runatlantis.io or tenant.ghe.com
atlantis server \
--atlantis-url="$URL" \
--gh-user="$USERNAME" \
--gh-token="$TOKEN" \
--gh-webhook-secret="$SECRET" \
--gh-hostname="$HOSTNAME" \
--repo-allowlist="$REPO_ALLOWLIST"

Para GitHub Enterprise Cloud, establece --gh-hostname con el hostname del tenant, como tenant.ghe.com, sin https:// ni un prefijo api..

GitLab

bash

atlantis server \
--atlantis-url="$URL" \
--gitlab-user="$USERNAME" \
--gitlab-token="$TOKEN" \
--gitlab-webhook-secret="$SECRET" \
--repo-allowlist="$REPO_ALLOWLIST"

GitLab Enterprise

bash

HOSTNAME=YOUR_GITLAB_ENTERPRISE_HOSTNAME # ex. gitlab.runatlantis.io
atlantis server \
--atlantis-url="$URL" \
--gitlab-user="$USERNAME" \
--gitlab-token="$TOKEN" \
--gitlab-webhook-secret="$SECRET" \
--gitlab-hostname="$HOSTNAME" \
--repo-allowlist="$REPO_ALLOWLIST"

Gitea

bash

GITEA_BASE_URL=YOUR_GITEA_BASE_URL # ex. https://gitea.example.com:3000
atlantis server \
--atlantis-url="$URL" \
--gitea-user="$USERNAME" \
--gitea-token="$TOKEN" \
--gitea-base-url="$GITEA_BASE_URL" \
--gitea-webhook-secret="$SECRET" \
--gitea-page-size=30 \
--repo-allowlist="$REPO_ALLOWLIST"

Bitbucket Cloud (bitbucket.org)

bash

atlantis server \
--atlantis-url="$URL" \
--bitbucket-user="$USERNAME" \
--bitbucket-token="$TOKEN" \
--bitbucket-webhook-secret="$SECRET" \
--repo-allowlist="$REPO_ALLOWLIST"

Bitbucket Server (aka Stash)

bash

BASE_URL=YOUR_BITBUCKET_SERVER_URL # ex. http://bitbucket.mycorp:7990
atlantis server \
--atlantis-url="$URL" \
--bitbucket-user="$USERNAME" \
--bitbucket-token="$TOKEN" \
--bitbucket-webhook-secret="$SECRET" \
--bitbucket-base-url="$BASE_URL" \
--repo-allowlist="$REPO_ALLOWLIST"

Azure DevOps

Se requieren un certificado y una clave privada si se usa autenticación Basic para webhooks.

bash

atlantis server \
--atlantis-url="$URL" \
--azuredevops-user="$USERNAME" \
--azuredevops-token="$TOKEN" \
--azuredevops-webhook-user="$ATLANTIS_AZUREDEVOPS_WEBHOOK_USER" \
--azuredevops-webhook-password="$ATLANTIS_AZUREDEVOPS_WEBHOOK_PASSWORD" \
--repo-allowlist="$REPO_ALLOWLIST"
--ssl-cert-file=file.crt
--ssl-key-file=file.key

Donde

$URL es la URL en la que se puede acceder a Atlantis
$USERNAME es el nombre de usuario de GitHub/GitLab/Gitea/Bitbucket/AzureDevops para el que generaste el token
$TOKEN es el access token que creaste. Si no quieres que esto se pase como argumento por razones de seguridad, puedes especificarlo en un archivo de configuración (consulta Configuration) o como una variable de entorno: ATLANTIS_GH_TOKEN o ATLANTIS_GITLAB_TOKEN o ATLANTIS_GITEA_TOKEN o ATLANTIS_BITBUCKET_TOKEN o ATLANTIS_AZUREDEVOPS_TOKEN
$SECRET es la clave aleatoria que usaste para el webhook secret. Si no quieres que esto se pase como argumento por razones de seguridad, puedes especificarlo en un archivo de configuración (consulta Configuration) o como una variable de entorno: ATLANTIS_GH_WEBHOOK_SECRET o ATLANTIS_GITLAB_WEBHOOK_SECRET o ATLANTIS_GITEA_WEBHOOK_SECRET
$REPO_ALLOWLIST es en qué repos puede ejecutarse Atlantis, por ej. github.com/runatlantis/* o github.enterprise.corp.com/*. Consulta --repo-allowlist para más detalles.

¡Atlantis ahora se está ejecutando!

TIP

Recomendamos ejecutarlo bajo algo como Systemd o Supervisord que lo reiniciará en caso de fallo.

Next Steps

Para asegurar que Atlantis se está ejecutando, carga su UI. De forma predeterminada Atlantis se ejecuta en el puerto 4141.
Ahora estás listo para agregar Webhooks a tus repos. Consulta Configuring Webhooks.

Despliegue ​

Resumen de arquitectura ​

Runtime ​

Enrutamiento ​

Datos ​

Despliegue ​

Kubernetes Helm Chart ​

Kubernetes Manifests ​

Manifest de StatefulSet ​

Manifest de Deployment ​

Enrutamiento y SSL ​

Kubernetes Kustomize ​

Requerido ​

GitLab ​

Gitea ​

GitHub ​

BitBucket ​

OpenShift ​

AWS Fargate ​

Google Kubernetes Engine (GKE) ​

Google Compute Engine (GCE) ​

Docker ​

Variantes de imagen ​

Customization ​

Microsoft Azure ​

Roll Your Own ​

Comando de inicio ​

GitHub ​

GitHub Enterprise ​

GitLab ​

GitLab Enterprise ​

Gitea ​

Bitbucket Cloud (bitbucket.org) ​

Bitbucket Server (aka Stash) ​

Azure DevOps ​

Next Steps ​

Despliegue

Resumen de arquitectura

Runtime

Enrutamiento

Datos

Despliegue

Kubernetes Helm Chart

Kubernetes Manifests

Manifest de StatefulSet

Manifest de Deployment

Enrutamiento y SSL

Kubernetes Kustomize

Requerido

GitLab

Gitea

GitHub

BitBucket

OpenShift

AWS Fargate

Google Kubernetes Engine (GKE)

Google Compute Engine (GCE)

Docker

Variantes de imagen

Customization

Microsoft Azure

Roll Your Own

Comando de inicio

GitHub

GitHub Enterprise

GitLab

GitLab Enterprise

Gitea

Bitbucket Cloud (bitbucket.org)

Bitbucket Server (aka Stash)

Azure DevOps

Next Steps