Restructured Documentation
Automatic Documentation Deployment / Sync Docs to https://kb.bunny-lab.io (push) Successful in 8s
Automatic Documentation Deployment / Sync Docs to https://kb.bunny-lab.io (push) Successful in 8s
This commit is contained in:
@@ -0,0 +1,82 @@
|
||||
---
|
||||
tags:
|
||||
- Containers
|
||||
- Docker
|
||||
- Containerization
|
||||
---
|
||||
|
||||
## Purpose
|
||||
This document will outline the general workflow of using Visual Studio Code to author and update custom containers and push them to a container registry hosted in Gitea. This will be referencing the `git-repo-updater` project throughout.
|
||||
|
||||
!!! note "Assumptions"
|
||||
This document assumes you are authoring the containers in Microsoft Windows, and does not include the fine-tuning necessary to work in Linux or MacOS environments. You are on your own if you want to author containers in Linux.
|
||||
|
||||
## Install Visual Studio Code
|
||||
The management of the Gitea repositories, Dockerfile building, and pushing container images to the Gitea container registry will all involve using just Visual Studio Code. You can download Visual Studio Code from this [direct download link](https://code.visualstudio.com/docs/?dv=win64user).
|
||||
|
||||
## Configure Required Docker Extensions
|
||||
You will need to locate and install the `Dev Containers`, `Docker`, and `WSL` extensions in Visual Studio Code to move forward. This may request that you install Docker Desktop onto your computer as part of the installation process. Proceed to do so, then when the Docker "Engine" is running, you can proceed to the next step.
|
||||
|
||||
!!! warning
|
||||
You need to have Docker Desktop "Engine" running whenever working with containers, as it is necessary to build the images. VSCode will complain if it is not running.
|
||||
|
||||
## Add Gitea Container Registry
|
||||
At this point, we need to add a registry to Visual Studio Code so it can proceed with pulling down the repository data.
|
||||
|
||||
- Click the Docker icon on the left-hand toolbar
|
||||
- Under "**Registries**", click "**Connect Registry...**"
|
||||
- In the dropdown menu that appears, click "**Generic Registry V2**"
|
||||
- Enter `https://git.bunny-lab.io/container-registry`
|
||||
- Registry Username: `nicole.rappe`
|
||||
- Registry Password or Personal Access Token: `Personal Access API Token You Generated in Gitea`
|
||||
- You will now see a sub-listing named "**Generic Registry V2**"
|
||||
- If you click the dropdown, you will see "**https://git.bunny-lab.io/container-registry**"
|
||||
- Under this section, you will see any containers in the registry that you have access to, in this case, you will see `container-registry/git-repo-updater`
|
||||
|
||||
## Add Source Control Repository
|
||||
Now it is time to pull down the repository where the container's core elements are stored on Gitea.
|
||||
|
||||
- Click the "**Source Control**" button on the left-hand menu then click the "**Clone Repository**" button
|
||||
- Enter `https://git.bunny-lab.io/container-registry/git-repo-updater.git`
|
||||
- Click the dropdown menu option "**Clone from URL**" then choose a location to locally store the repository on your computer
|
||||
- When prompted with "**Would you like to open the cloned repository**", click the "**Open**" button
|
||||
|
||||
## Making Changes
|
||||
You will be presented with four files in this specific repository. `.env`, `docker-compose.yml`, `Dockerfile`, and `repo_watcher.sh`
|
||||
|
||||
- `.env` is the environment variables passed to the container to tell it which ntfy server to talk to, which credentials to use with Gitea, and which repositories to download and push into production servers
|
||||
- `docker-compose.yml` is an example docker-compose file that can be used in Portainer to deploy the server along with the contents of the `.env` file
|
||||
- `Dockerfile` is the base of the container, telling docker what operating system to use and how to start the script in the container
|
||||
- `repo_watcher.sh` is the script called by the `Dockerfile` which loops checking for updates in Gitea repositories that were configured in the `.env` file
|
||||
|
||||
### Push to Repository
|
||||
When you make any changes, you will need to first commit them to the repository
|
||||
|
||||
- Save all of the edited files
|
||||
- Click the "**Source Control**" button in the toolbar
|
||||
- Write a message about what you changed in the commit description field
|
||||
- Click the "**Commit**" button
|
||||
- Click the "**Sync Changes**" button that appears
|
||||
- You may be presented with various dialogs, just click the equivalant of "**Yes/OK**" to each of them
|
||||
|
||||
### Build the Dockerfile
|
||||
At this point, we need to build the dockerfile, which takes all of the changes and packages it into a container image
|
||||
|
||||
- Navigate back to the file explorer inside of Visual Studio Code
|
||||
- Right-click the `Dockerfile`, then click "**Build Image...**"
|
||||
- In the "Tag Image As..." window, type in `git.bunny-lab.io/container-registry/git-repo-updater:latest`
|
||||
- When you navigate back to the Docker menu, you will see a new image appear under the "**Images**" section
|
||||
- You should see something similar to "Latest - X Seconds Ago` indicating this is the image you just built
|
||||
- Delete the older image(s) by right-clicking on them and selecting "**Remove...**"
|
||||
- Push the image to the container registry in Gitea by right-clicking the latest image, and selecting "**Push...**"
|
||||
- In the dropdown menu that appears, enter `git.bunny-lab.io/container-registry/git-repo-updater:latest`
|
||||
- You can confirm if it was successful by navigating to the [Gitea Container Webpage](https://git.bunny-lab.io/container-registry/-/packages/container/git-repo-updater/latest) and seeing if it says "**Published Now**" or "**Published 1 Minute Ago**"
|
||||
|
||||
!!! warning "CRLF End of Line Sequences"
|
||||
When you are editing files in the container's repository, you need to ensure that Visual Studio Code is editing that file in "**LF**" mode and not "**CRLF**". You can find this toggle at the bottom-right of the VSCode window. Simply clicking on the letters "**CRLF**" will let you toggle the file to "**LF**". If you do not make this change, the container will misunderstand the dockerfile and/or scripts inside of the container and have runtime errors.
|
||||
|
||||
## Deploy the Container
|
||||
You can now use the `.env` file along with the `docker-compose.yml` file inside of Portainer to deploy a stack using the container you just built / updated.
|
||||
|
||||
## Related Documentation
|
||||
- [Related Containers Documentation](<../../../reference/Containers/index.md>) — Find the connected deployments, procedures, and references for this subject.
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
tags:
|
||||
- Docker
|
||||
- Macvlan
|
||||
- Networking
|
||||
---
|
||||
|
||||
## Purpose
|
||||
You may find that you only have one network adapter on a server / VM and need to have multiple virtual networks associated with it. For example, Home Assistant exists on the `192.168.3.0/24` network but it needs to also access devices on the `192.168.4.0/24` surveillance network. To facilitate this, we will make a MACVLAN Sub-Interface. This will make a virtual interface that is parented to the actual physical interface.
|
||||
|
||||
!!! info "Assumptions"
|
||||
It is assumed that you are running Rocky Linux (or CentOS / RedHat).
|
||||
|
||||
## Create the Permanent Sub-Interface
|
||||
You will begin with making a new interface, it will have the name `macvlan0`.
|
||||
|
||||
```sh
|
||||
nmcli connection add type macvlan ifname surveillance dev ens18 mode bridge ipv4.method manual ipv4.addresses 192.168.4.100/24
|
||||
nmcli connection up macvlan-surveillance
|
||||
nmcli connection show
|
||||
```
|
||||
|
||||
## Bind a Docker Network to the Sub-Interface
|
||||
Now you need to run the following command to allow docker to use this interface for the `surveillance_network`
|
||||
|
||||
```sh
|
||||
docker network create -d macvlan --subnet=192.168.4.0/24 --gateway=192.168.4.1 -o parent=surveillance surveillance_network
|
||||
```
|
||||
|
||||
## Related Documentation
|
||||
- [Related Containers Documentation](<../../../reference/Containers/index.md>) — Find the connected deployments, procedures, and references for this subject.
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
tags:
|
||||
- Containers
|
||||
- Docker
|
||||
- Bash
|
||||
- Scripting
|
||||
- Linux
|
||||
---
|
||||
|
||||
## Purpose
|
||||
If you find that you need to migrate a container, along with any supporting files, permissions, etc from an old server to a new server, rsync helps make this as painless as possible.
|
||||
Be sure to perform the following steps to make sure that you can copy the container's files.
|
||||
|
||||
!!! warning
|
||||
You need to stop the running containers on the old server before copying their data over, otherwise the state of the data may be unstable. Once you have migrated the data, you can spin up the containers on the new server and confirm they work before deleting the data on the old server.
|
||||
|
||||
On the destination (new) server, the directory needs to exist and be writable via the person copying the data over SSH:
|
||||
|
||||
## Copying Data Between the Old and New Servers
|
||||
=== "Safe Method"
|
||||
|
||||
```sh
|
||||
sudo mkdir -p /srv/containers/example
|
||||
sudo chmod 740 /srv/containers/example
|
||||
sudo chown nicole:nicole /srv/containers/example
|
||||
```
|
||||
|
||||
=== "Quick & Dirty Method"
|
||||
|
||||
```sh
|
||||
sudo mkdir -p /srv/containers
|
||||
sudo chmod 777 /srv/containers
|
||||
```
|
||||
|
||||
On the source (old) server, perform an rsync over to the new server, authenticating yourself as you will be prompted to do so:
|
||||
|
||||
=== "Safe Method"
|
||||
|
||||
```sh
|
||||
rsync -avz -e ssh --progress /srv/containers/example/* nicole@192.168.3.30:/srv/containers/example
|
||||
```
|
||||
|
||||
=== "Quick & Dirty Method"
|
||||
|
||||
```sh
|
||||
rsync -avz -e ssh --progress /srv/containers/example nicole@192.168.3.30:/srv/containers
|
||||
```
|
||||
|
||||
=== "Quick & Dirty w/ Provided SSH Key Method"
|
||||
This method assumes that you have the private key for your SSH-based authentication locally on the server somewhere safe with permissions `chmod 600` applied to it. In this example, I placed the private key at `/tmp/id_rsa_OpenSSH`.
|
||||
|
||||
```sh
|
||||
rsync -avz -e "ssh -i /tmp/id_rsa_OpenSSH" --progress /srv/containers/pihole nicole@192.168.3.62:/srv/containers
|
||||
```
|
||||
|
||||
## Spinning Up Docker / Portainer Stack
|
||||
Once everything has been moved over, copy the `docker-compose` and `.env` (environment variables) from the old server to the new one, pointing to the same location since we maintained the same folder structure, and the container should spin up like nothing ever happened.
|
||||
|
||||
## Related Documentation
|
||||
- [Related Containers Documentation](<../../../reference/Containers/index.md>) — Find the connected deployments, procedures, and references for this subject.
|
||||
Reference in New Issue
Block a user