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

Open
  • Is something wrong?
#314 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
40/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Active
Tech stack
docker, github-actions, gitlab, kubernetes, shell
Domain
cli, devops, documentation

Research direction

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.

Written by the indexing model from the issue text.

Description

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.
Dominant language
TypeScript
Stars
0
Forks
0
Avg merge
1h 20m
Merged PRs (30d)
1

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from components-web-app/docs

All issues in components-web-app/docs

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.