add argocd to essentials

Author: gilesknap

docs/explanations/introduction.md

@@ -202,6 +202,14 @@ There are these types of CI:
       or other OCI registry
 ```
 
+### Continuous Deployment
+
+ArgoCD is a Kubernetes controller that continuously monitors running applications and compares the current state with the desired state described in a git repository. If the current state does not match the desired state, ArgoCD will attempt to reconcile the two.
+
+For this purpose each services repository will have a companion deployment repository which tracks which versions of each IOC in the services repository should currently be deployed to the cluster. This list of IOC versions is in a single YAML file and updating this file and pushing it to the deployment repository will trigger ArgoCD to update the cluster.
+
+In this fashion changes to IOC versions are tracked in git and it is easy to roll back to the same state as a given date because there is a complete record.
+
 ## Scope
 
 This project initially targets x86_64 Linux Soft IOCs and RTEMS IOC running

docs/overview.md

@@ -18,8 +18,8 @@ There are 5 themes to this strategy:
   Source, container and helm repositories manage all of the above assets.
   No shared file systems required.
 
-:Continuous Integration / Deployment:
+:Continuous Integration / Continuous Deployment:
   Source repositories automatically build containers and helm charts,
   delivering them to OCI registries. Services repositories automatically deploy
-  IOCs to Kubernetes clusters.
+  IOCs to Kubernetes clusters using ArgoCD.
 ```

docs/reference/glossary.md

@@ -8,8 +8,8 @@ A repository that contains the definitions for a group of IOCs instances and oth
 
 epics-containers supports two kinds of services repositories:
 
-- **Kubernetes** services repositories. These are for deployment into a Kubernetes cluster. Each repositoriy contains a set of **Helm Charts** all of which will deploy into a single namespace in a single Kubernetes Cluster.
-- **Local Machine** services repositories. These are for deployment to a local machine using docker-compose. Each repository contains a set *compose.yaml* files that describe how to deploy a set of services to the local machine. These could potentially be used for production at a facility which does not use Kuberentes, but are primarily for development, testing and the earlier tutorials in this documenttation.
+- **Kubernetes** services repositories. These are for deployment into a Kubernetes cluster. Each repository contains a set of **Helm Charts** all of which will deploy into a single namespace in a single Kubernetes Cluster.
+- **Local Machine** services repositories. These are for deployment to a local machine using docker-compose. Each repository contains a set *compose.yaml* files that describe how to deploy a set of services to the local machine. These could potentially be used for production at a facility which does not use Kubernetes, but are primarily for development, testing and the earlier tutorials in this documentation.
 
 (edge-containers-cli)=
 ## edge-containers-cli

docs/tutorials/setup_workstation.md

@@ -116,12 +116,15 @@ Note that each time you open a new shell you will need to activate the virtual e
 
 (ec)=
 
-### edge-containers-cli
+### edge-containers-cli and copier
 
 Above we set up a python virtual environment. Now we will install the {any}`edge-containers-cli` python tool into that environment. This tool is used to manage the IOC instances in Kubernetes and is only required for the later tutorials.
 
+We also take this opportunity to install `copier` which is used to copy the templates for the services repositories and generic IOCs.
+
 ```bash
 pip install edge-containers-cli
+pip install copier
 ```
 
 See {any}`CLI` for more details.
@@ -147,10 +150,9 @@ version of git will work.
 
 You don't need Kubernetes yet.
 
-The following tutorials will take you through creating, deploying and
-debugging IOC instances, generic IOCs and support modules.
+The following tutorials will take you through creating, deploying and debugging IOC instances, generic IOCs and support modules.
 
-For simplicity we don't encourage using Kubernetes at this stage. Instead we will deploy containers to the local workstation's docker or podman instance.
+For simplicity we don't encourage using Kubernetes at this stage. Instead we will deploy containers to the local workstation's docker or podman instance using docker compose.
 
 If you are planning not to use Kubernetes at all then now might be a good time to install an alternative container management platform such as [Portainer](https://www.portainer.io/). Such tools will help you visualise and manage your containers across a number of servers. These are not required and you could just manage everything from the docker compose command line if you prefer.