move dev scripts to tools/, migrate to bws, use example.com in docs
Provision server / provision (push) Successful in 7s
Provision server / provision (push) Successful in 7s
- Move new-app.sh, new-service.sh, remove-app.sh from scripts/ to tools/ - Migrate new-app.sh and remove-app.sh from bw to bws - Replace real domains with example.com in documentation and help text
This commit is contained in:
+24
-24
@@ -41,52 +41,53 @@ fresh server.
|
||||
From your dev machine (single command):
|
||||
|
||||
```bash
|
||||
./scripts/new-app.sh hcsuzuki.net
|
||||
./tools/new-app.sh example.com
|
||||
```
|
||||
|
||||
**Prerequisites:**
|
||||
- Bitwarden vault must contain `hantim-new-app-script`, `hantim-vultr-api-key`,
|
||||
and `hantim-server-deploy`
|
||||
- Bitwarden Secrets Manager must contain `hantim-new-app-script`,
|
||||
`hantim-vultr-api-key`, and `hantim-deploy-ssh-private-key`
|
||||
- Domain nameservers must be pointed to Vultr (configured on directnic.com)
|
||||
- Dependencies: `bw`, `jq`, `dig`
|
||||
- Dependencies: `bws`, `jq`, `dig`
|
||||
- `BWS_ACCESS_TOKEN` env var or token saved at `~/.config/hantim/bws-token`
|
||||
|
||||
**What happens (fully automated):**
|
||||
1. Resolves server IP from `hantim.net`
|
||||
2. Fetches Gitea API token, Vultr API key, and deploy SSH key from Bitwarden
|
||||
2. Fetches Gitea API token, Vultr API key, and deploy SSH key from Bitwarden Secrets Manager
|
||||
3. Creates DNS zone on Vultr (if needed) and A records for bare + www
|
||||
4. Waits for DNS to propagate
|
||||
5. Creates Gitea repo `hantim/hcsuzuki.net` from `static-site-template`
|
||||
5. Creates Gitea repo `hantim/example.com` from `static-site-template`
|
||||
6. Creates local files:
|
||||
- `docker/hcsuzuki.net/compose.yml` (container name: `hcsuzuki_net`)
|
||||
- `.gitea/workflows/deploy-hcsuzuki.net.yml`
|
||||
- `docker/nginx/conf.d/hcsuzuki.net.conf` (HTTP->HTTPS, bare->www, proxy)
|
||||
- `docker/example.com/compose.yml` (container name: `example_com`)
|
||||
- `.gitea/workflows/deploy-example.com.yml`
|
||||
- `docker/nginx/conf.d/example.com.conf` (HTTP->HTTPS, bare->www, proxy)
|
||||
7. SSHes to server as deploy user, issues SSL cert via webroot (zero downtime)
|
||||
8. Commits and pushes hantim-server (triggers deploy)
|
||||
9. Triggers initial build of the app repo via Gitea API
|
||||
10. Polls `https://www.hcsuzuki.net` until it responds (up to 3 minutes)
|
||||
10. Polls `https://www.example.com` until it responds (up to 3 minutes)
|
||||
|
||||
After the site is live, clone the app repo and customize:
|
||||
|
||||
```bash
|
||||
git clone git@git.timothykim.net:hantim/hcsuzuki.net.git
|
||||
cd hcsuzuki.net
|
||||
git clone git@git.timothykim.net:hantim/example.com.git
|
||||
cd example.com
|
||||
# edit static/index.html, etc.
|
||||
git add . && git commit -m "initial content" && git push
|
||||
```
|
||||
|
||||
## 4. Update app code
|
||||
|
||||
Push a change to the app repo (e.g., `timothykim.net`):
|
||||
Push a change to the app repo (e.g., `example.com`):
|
||||
|
||||
```bash
|
||||
cd timothykim.net
|
||||
cd example.com
|
||||
# make changes
|
||||
git add . && git commit -m "update content" && git push
|
||||
```
|
||||
|
||||
**What happens:**
|
||||
1. Gitea Actions runs `build.yml`: builds Docker image, pushes to registry
|
||||
2. SSHes into server, runs `deploy-timothykim.net`
|
||||
2. SSHes into server, runs `deploy-example.com`
|
||||
3. `deploy.sh` pulls latest hantim-server, pulls new image, restarts container
|
||||
|
||||
No manual steps needed.
|
||||
@@ -96,14 +97,14 @@ No manual steps needed.
|
||||
Edit a compose file in this repo and push:
|
||||
|
||||
```bash
|
||||
vim docker/timothykim.net/compose.yml
|
||||
git add docker/timothykim.net/compose.yml
|
||||
git commit -m "update timothykim.net config"
|
||||
vim docker/example.com/compose.yml
|
||||
git add docker/example.com/compose.yml
|
||||
git commit -m "update example.com config"
|
||||
git push
|
||||
```
|
||||
|
||||
**What happens:**
|
||||
1. `deploy-timothykim.yml` workflow triggers (path match)
|
||||
1. `deploy-example.com.yml` workflow triggers (path match)
|
||||
2. `deploy.sh` pulls latest code, pulls image, runs `docker compose up -d`
|
||||
|
||||
## 6. Update nginx config
|
||||
@@ -111,8 +112,8 @@ git push
|
||||
Edit an nginx config in this repo and push:
|
||||
|
||||
```bash
|
||||
vim docker/nginx/conf.d/timothykim.net.conf
|
||||
git add docker/nginx/conf.d/timothykim.net.conf
|
||||
vim docker/nginx/conf.d/example.com.conf
|
||||
git add docker/nginx/conf.d/example.com.conf
|
||||
git commit -m "update nginx config"
|
||||
git push
|
||||
```
|
||||
@@ -127,9 +128,8 @@ git push
|
||||
5. Runs `docker compose up -d` and reloads nginx
|
||||
|
||||
**Note:** Each conf file must contain server blocks for only one domain. The
|
||||
cert name is derived from the filename (e.g. `hcsuzuki.net.conf` -> cert
|
||||
`hcsuzuki.net`). Redirect-only domains like `hcsuzukiviolin.com` get their
|
||||
own conf file.
|
||||
cert name is derived from the filename (e.g. `example.com.conf` -> cert
|
||||
`example.com`). Redirect-only domains get their own conf file.
|
||||
|
||||
## 7. Re-run configure on existing server
|
||||
|
||||
|
||||
Reference in New Issue
Block a user