Deploy to one server page, and create-cwa's new questions

Abierto
  • ¿Algo no está bien?
#314 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
40/100
Tipo de issue
Documentación
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
docker, github-actions, gitlab, kubernetes, shell
Área
cli, devops, documentation

Línea de trabajo

Start with the scripts this page describes: bin/server/init, bin/server/deploy.sh, bin/server/backup.sh, bin/server/restore.sh, bin/server/cron.example, bin/devops/server-deploy.sh and the server.yml workflow, plus commits 1aec0c9 and d84cbe7 in components-web-app. Done means a new deployment page marked as preview that covers setup, first deploy, later deploys, the CI variables, backups and the move to Kubernetes, and create-cwa docs that cover the new questions and flags.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

From components-web-app #212, now on main (commits 1aec0c9 and d84cbe7, in the next release). The docs describe current main.

1. A "Deploy to one server" page (new, under deployment). Mark it as a preview: no production site has run on it yet.

  • Server setup: Docker with the compose plugin, rsync and curl, and a deploy user in the docker group with the pipeline's public key.
  • First deploy: run the CI job once, which copies the files and then stops. On the server, run cd cwa && sh bin/server/init (it writes .env.prod, mode 600: secrets, JWT keys, SITE_HOST, SITE_ALIASES, MAILER_DSN), then sh bin/server/deploy.sh --fixtures.
  • Every later deploy is GitLab's manual production server job or GitHub's "Deploy to server" workflow (server.yml). Both run bin/devops/server-deploy.sh, which copies the commit with rsync and runs bin/server/deploy.sh there. That builds, backs up before pending migrations, starts app then php, purges, generates image variants and warms the cache. rsync never sends or deletes what git ignores (.env.prod, backups/).
  • Variables:
    • CWA_CI_SERVER_HOST makes the project single-server: every Kubernetes job skips. Don't make it Protected.
    • CWA_CI_SERVER_SSH_KEY: a secret, the key as is or as base64 on one line.
    • CWA_CI_SERVER_KNOWN_HOSTS: required, the output of ssh-keyscan. Host keys are always checked.
    • Optional: CWA_CI_SERVER_USER (deploy), CWA_CI_SERVER_PORT (22), CWA_CI_SERVER_PATH (cwa, under the user's home).
  • Backups and restore: bin/server/backup.sh (database dump, media and Caddy certificates, keeping 5) and restore.sh. Add a note that a backup on the same disk isn't a backup. Daily jobs: bin/server/cron.example.
  • Moving from one server to Kubernetes:
    • rsync the media into GCLOUD_PATH_PREFIX;
    • take a final dump in maintenance mode;
    • set the secrets as CI variables (the deploy reads them first);
    • deploy with the staging issuer first, then switch to letsencrypt-prod.

Images: the server builds them today. Pulling the images CI built is being added next; I'll comment here when it lands.

2. The create-cwa page:

  • Pipeline: GitHub Actions, GitLab CI, or "None yet".
  • "Deploy to?" (only with a pipeline): a Kubernetes cluster, or one server with Docker (preview). --deploy kubernetes|server.
  • Components, renamed by what an editor gets:
    • Navigation menu, Rich text (TipTap), Images, Blog, Nested pages, Example form.
    • The first three are pre-selected, and are what --yes and --ci pick (was none).
    • --features default|all|none|a,b.
  • "Start with example pages?" replaces the fixtures yes/no. --content demo|home|empty; --fixtures and --no-fixtures still work, as demo and empty.
    • demo: a home page plus an example of each chosen component;
    • home: just the layout and a home page;
    • empty: only the admin login.
  • The generated README has a deploy section for the chosen target.
Lenguaje dominante
TypeScript
Estrellas
0
Forks
0
Merge medio
1 h 20 min
PR fusionados (30 d)
1

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de components-web-app/docs

Todos los issues de components-web-app/docs

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.