| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| project:coopcloud_spike [2025/11/25 10:58] – [Notes for Coop Cloud] jade | project:coopcloud_spike [2025/12/05 13:24] (current) – [Experiment 3: Run Kiwix on Raspberry Pi] jade |
|---|
| ===== Experiments ===== | ===== Experiments ===== |
| |
| - Install an existing Co-op Cloud app with abra | - ✅ Install an existing Co-op Cloud app with abra |
| - Build a [[https://kiwix.org/en/|Kiwix]] recipe for Co-op Cloud | - ✅ Build a [[https://kiwix.org/en/|Kiwix]] recipe for Co-op Cloud |
| - Run the Co-op Cloud Kiwix recipe on a Raspberry Pi | - ✅ Run the Co-op Cloud Kiwix recipe on a Raspberry Pi |
| - //(unknown experiment to verify extending capabilities, determine how to test this once we know more)// | - ✅ Deploy a dummy app that can list other installed apps |
| |
| ==== Experiment 1: Try using abra ==== | ==== Experiment 1: Try using abra ==== |
| |
| I'm leaning towards thinking that Abra should be run on the development machine, not on the server. That means that Merri-bek Tech Node Stewards (Operators in Co-op cloud speak) could share a git repository and store the abra config there. I'd like to test this approach. | I'm leaning towards thinking that Abra should be run on the development machine, not on the server. That means that Merri-bek Tech Node Stewards (Operators in Co-op cloud speak) could share a git repository and store the abra config there. I'd like to test this approach. |
| | |
| | ==== Experiment 2: Build Kiwix Recipe ==== |
| | |
| | This was pretty straightforward to build. I used abra locally, which seems pretty essential for local development of a recipe. It handled things pretty well. It's up and running (for the moment) at [[https://kiwix.spike2.merri-bek.tech/|https://kiwix.spike2.merri-bek.tech/]] |
| | |
| | ==== Experiment 3: Run Kiwix on Raspberry Pi ==== |
| | |
| | There seems to be no fundamental obstacle to running kiwix on a Raspberry Pi, providing you pick a container image built for the pi. My recipe uses the image provided by [[https://www.offlineinternet.org/|offline internet]] - [[https://hub.docker.com/r/offlineinternet/kiwix|offlineinternet/kiwix]]. |
| | |
| | The recipe that I build is a draft at this stage. It has the following compose |
| | |
| | <code> |
| | --- |
| | services: |
| | kiwix-serve: |
| | image: offlineinternet/kiwix:latest |
| | networks: |
| | - proxy |
| | volumes: |
| | - kiwix_data:/data |
| | deploy: |
| | restart_policy: |
| | condition: on-failure |
| | labels: |
| | - "traefik.enable=true" |
| | - "traefik.http.services.${STACK_NAME}.loadbalancer.server.port=8080" |
| | - "traefik.http.routers.${STACK_NAME}.rule=Host(`${DOMAIN}`${EXTRA_DOMAINS})" |
| | - "traefik.http.routers.${STACK_NAME}.entrypoints=web-secure" |
| | - "traefik.http.routers.${STACK_NAME}.tls.certresolver=${LETS_ENCRYPT_ENV}" |
| | - "coop-cloud.${STACK_NAME}.version=" |
| | networks: |
| | proxy: |
| | external: true |
| | volumes: |
| | kiwix_data: |
| | </code> |
| | |
| | Here are some things I learned: |
| | |
| | * There is no way to mark the Coop Cloud recipe as supporting particular platforms, despite the fact that the docker image is tagged that way. |
| | * As part of this I ran this on a pi on my local network at radish house. Accessing it on my local network as both radish.local and via an external domain like radish.nodes.merri-bek.tech was hard. I had to pick one. There is an EXTRA_DOMAINS feature in the traefik recipe to play with though. |
| | * If serving locally, eg at radish.local, Traefik SSL certificate generation isn't going to work. Instead, locally signed certificates are needed. There is information about how to do that in handbook under [[https://docs.coopcloud.tech/operators/handbook/#running-an-offline-coop-cloud-server|Running an Offline Coop Cloud Server]]. There is also a certificate generator called [[https://git.coopcloud.tech/escuela-comun/certificados|certificados]]. |
| | ==== Experiment 4: Ensure that an app can get access to the running stacks ==== |
| | |
| | I conducted this by building a dummy recipe which I called spikespy. It had the following config: [[https://gist.github.com/jadehopepunk/8ed43d9bdf57b5eaaa66e5b3f0fadece|compose.yml]] |
| | |
| | When I log into the debian/nginx image that is connected to the socket proxy, I can ''apt update && apt install docker-cli''. Then docker is there and I can use it without having the normal docker socket mounted, by specifying the host. |
| | |
| | For example, it works if I do: |
| | |
| | <code> |
| | docker -H tcp://socket-proxy:2375 ps |
| | </code> |
| | |
| | But, it is configured to not allow docker exec, and so if I do: |
| | |
| | <code> |
| | docker -H tcp://socket-proxy:2375 exec -it effe902f3e66 sh |
| | </code> |
| | |
| | I get a forbidden error. |
| |
| ===== Notes for Coop Cloud ===== | ===== Notes for Coop Cloud ===== |
| |
| * When using abra on the server (obviously not the golden path, so may be unimportant) the default server is not given a domain (it's just default), so each app needs to have that domain entered on creation. Otherwise it'll use ''traefik.default'' as the domain. This is fine but a little awkward. It'd be nice if the server domain was set in one place. | - When using abra on the server (obviously not the golden path, so may be unimportant) the default server is not given a domain (it's just default), so each app needs to have that domain entered on creation. Otherwise it'll use ''traefik.default'' as the domain. This is fine but a little awkward. It'd be nice if the server domain was set in one place. |
| * In the New Operators Tutorial, it's light on [[https://docs.coopcloud.tech/operators/tutorial/#server-configuration|how to provision servers]], which is fine, but I think it should probably give some advice on whether to ssh in as root or a non-root user. I'm inferring that the usual approach is a non-root user, maybe with sudo access, but that access isn't used by abra anyway. Does this user need sudo? Do people often use a user per operator (for traceability) or a single abra user? | - In the New Operators Tutorial, it's light on [[https://docs.coopcloud.tech/operators/tutorial/#server-configuration|how to provision servers]], which is fine, but I think it should probably give some advice on whether to ssh in as root or a non-root user. I'm inferring that the usual approach is a non-root user, maybe with sudo access, but that access isn't used by abra anyway. Does this user need sudo? Do people often use a user per operator (for traceability) or a single abra user? |
| * The New Operators tutorial could perhaps help people through edge cases of server setup a bit more. For example, a fresh Ubuntu noble VPS on Digital Ocean hits the problem with swarm init where it detects two IP addresses and it needs you to use ''--advertise-addr''. | - The New Operators tutorial could perhaps help people through edge cases of server setup a bit more. For example, a fresh Ubuntu noble VPS on Digital Ocean hits the problem with swarm init where it detects two IP addresses and it needs you to use ''--advertise-addr''. |
| * In the New Operators tutorial, it suggests the command ''groups | grep docker'' is to check if the docker group exists. Isn't that command actually to check if the current user is in the docker group already? Especially in the context of the next command ''groupadd docker'' which then invariably says "this group already exists" | - In the New Operators tutorial, it suggests the command ''groups | grep docker'' is to check if the docker group exists. Isn't that command actually to check if the current user is in the docker group already? Especially in the context of the next command ''groupadd docker'' which then invariably says "this group already exists" |
| | - The reason I first tried using abra on the server was actually just that the documentation for installing abra is a bit subtle about switching to using your own machine after all previous sections had been running the commands on the server. It is written there, in the first sentence //Now we can install abra locally on your machine// but I'd probably make it strong. Like "Let's now switch you your development machine for the next step. You should have a computer with these dependencies installed, xxx. If you don't, there's another option to run abra on the server which is covered in the handbook here..." |
| | - It might be nice if the documentation mentioned that on deploying a new app, you'll need to refresh the page a few times to cause the SSL certificate to get fetched. |
