Feature/ioc on cicd runner (#71)

Run `ioc ...` from cicd runner, remove ansible and cli commands
Reviewed-on: #71

docs/developer/ansible.md

@@ -1,36 +0,0 @@
-# Ansible
-
-## Running a playbook manually
-
-Set vars on command line:
-
-```
-ansible-playbook ansible/playbooks/add-new-service.yml \
-            -i ansible/hosts.yml \
-            --extra-vars="repo_root=${{ github.workspace }} agebd_env=dev service_name_lower=<service dir name>" \
-            -v
-```
-
-### Install an IOC
-```
-ansible-playbook ansible/playbooks/ioc-install.yml \
-            -i ansible/hosts.yml \
-            --extra-vars="agebd_env=dev branch_name=feature/add-service-playground service_name_lower=playground ioc_port=50003" \
-            -v
-```
-
-### Start an IOC
-```
-ansible-playbook ansible/playbooks/ioc-start.yml \
-            -i ansible/hosts.yml \
-            --extra-vars="service_name_lower=playground ioc_port=50003" \
-            -v
-```
-
-### Restart an IOC
-```
-ansible-playbook ansible/playbooks/ioc-restart.yml \
-            -i ansible/hosts.yml \
-            --extra-vars="agebd_env=dev branch_name=feature/add-service-playground service_name_lower=playground" \
-            -v
-```

docs/developer/cicd_runner.md

@@ -3,9 +3,11 @@
 ## Hosts
 
 - `sls-vserv-bd-01(-dev)`
-    - Runs shellbox commands (and `ioc install ...`?)
+    - Runs the shellbox commands, which the runner triggers over `ssh`
+      (see `.gitea/scripts/ioc-start.sh`)
 - `sls-vserv-bd-hla01(-dev)`
-    - Runs everything else
+    - Runs the runner itself, and therefore everything else: the deployments
+      to `/sls/bd/hla/<env>/` and the `ioc ...` commands
 
 ## Setup
 
@@ -182,3 +184,28 @@ The gitea actions run as user `svcusr-sls2hla`
 ### #TODO: this is a temporary workaround
 I created an ssh key on `sls-vserv-bd-hla01-dev` (where the runner runs), and added the public key to my
 gitea profile ssh keys. That way the `svcusr` can clone the repos I can clone.
+
+
+## Setup `sls-vserv-bd-01-dev`
+
+On `sls-vserv-bd-hla01-dev`
+
+```
+sudo su - svcusr-sls2hla
+cat ~/.ssh/id_ed25519.pub
+```
+
+If it does not exist yet:
+```
+sudo su - svcusr-sls2hla
+ssh-keygen -t ed25519 -N "" -C "svcusr-sls2hla@sls-vserv-bd-hla01-dev" -f ~/.ssh/id_ed25519
+cat ~/.ssh/id_ed25519.pub
+```
+
+```
+ssh sls-vserv-bd-01-dev            # lands as your own user
+sudo install -d -m 700 -o svcusr-sls2hla -g unx-nogroup /home/svcusr-sls2hla /home/svcusr-sls2hla/.ssh
+echo '<paste the pubkey>' | sudo tee /home/svcusr-sls2hla/.ssh/authorized_keys
+sudo chown svcusr-sls2hla:unx-nogroup /home/svcusr-sls2hla/.ssh/authorized_keys
+sudo chmod 600 /home/svcusr-sls2hla/.ssh/authorized_keys
+```

docs/developer/ioc/ioc.md

@@ -1,6 +1,8 @@
 # IOC
 
-The following instructions explain the basics of starting and managing IOCs on the IOC host. 
+The following instructions explain the basics of starting and managing IOCs on the IOC host.
+They describe the manual steps. In practice the CI/CD runner does this for you, see
+[Automation](#automation) below. 
 
 - TODO: some iocs not associated to a service, where to put? 
 - TODO: need to dev/prod template them too
@@ -92,3 +94,20 @@ sudo shellbox start 50045       # start ioc
 sudo shellbox log 50045 -f      # log file (tail)
 exit                            # exit ssh
 ```
+
+
+## Automation
+
+Installing, starting and restarting IOCs is done by the gitea runner, not by hand:
+
+- `.gitea/scripts/ioc-install.sh <service-name> <dev|prod>`
+- `.gitea/scripts/ioc-start.sh <service-name> <dev|prod>` (shellbox, over `ssh`)
+- `.gitea/scripts/ioc-restart.sh <service-name> <dev|prod>`
+
+The scripts operate on the deployed IOC files in
+`/sls/bd/hla/<env>/services/<service-name>/current/ioc`, so a service has to be deployed
+before its IOC can be installed.
+
+They run automatically when a new service is added (`.gitea/workflows/add-new-service.yml`),
+and can be triggered manually for any service (or `all` services) through the `Ioc` workflow
+(`.gitea/workflows/ioc.yml`) in the gitea Actions tab.