Promoting applications from test to production - Revision history

Lynn: /* Incorporating the docker-compose.yml file into the stack */

2026-09-10T01:54:51Z

Incorporating the docker-compose.yml file into the stack

← Older revision		Revision as of 01:54, 10 September 2026
Line 69:		Line 69:

	At volumes, it gets a little interesting. The definition is split by a ':' with the left part defining the external location and the right part defining where it will appear in the file layout where the application runs. The first definition is for tank. The ${APPS_POOL} variable points to the tank storage pool while the ${MEDIA_POOL} to the big bucket that holds the bulk of everything. The APPS_POOL is organized by the application and if you examine the directory layout in tank it follows a convention that includes the stack and container in the definition. The MEDIA_POOL really doesn't generally have an application focus. For example, several applications all work with video files.		At volumes, it gets a little interesting. The definition is split by a ':' with the left part defining the external location and the right part defining where it will appear in the file layout where the application runs. The first definition is for tank. The ${APPS_POOL} variable points to the tank storage pool while the ${MEDIA_POOL} to the big bucket that holds the bulk of everything. The APPS_POOL is organized by the application and if you examine the directory layout in tank it follows a convention that includes the stack and container in the definition. The MEDIA_POOL really doesn't generally have an application focus. For example, several applications all work with video files.
			====After successfully deploying the application====
			After editing the stack, click on deploy. If you have new, or updated, containers this can take a couple of minutes while everything is fetched and the applications started. Most of the time, a failure at this point is due to something simple so look carefully.

			Initially, clicking on the port number should launch the app, If you get this far, what is left is putting it in the appropriate location, making it known to the DNS server and updating the tables.

			====Moving the application====
			New applications will go into new stack, not the one that was originally defined. Over in tank, move the configuration files to the proper location. {{note \| Probably going to change this so they don't need to be moved}}. Edit the compose stanza to reflect the change.

			Add a line of the form:

			weaver.${DOMAIN:-home.arpa};${TRUENAS_HOST_IP:-192.168.1.1}

			to the pi.hole definition in the dns-dhcp stack. This will make weaver available as weaver.maceys.net, or weaver.home.arpa.

			Add the appropriate definition for, in our case, weaver.proxy. {{note \| Chicke or egg?}}

Lynn: /* Incorporating the docker-compose.yml file into the stack */

2026-09-10T01:30:37Z

Incorporating the docker-compose.yml file into the stack

← Older revision		Revision as of 01:30, 10 September 2026
Line 57:		Line 57:
	- 7090:9090		- 7090:9090
	volumes:		volumes:
	- /mnt/${APPS_POOL:-tank}/docker/apps/~~test~~/weaver:/config		- /mnt/${APPS_POOL:-tank}/docker/apps/media/weaver:/config
	# use the same host path and container path as Scryer		# use the same host path and container path as Scryer
	- /mnt/${MEDIA_POOL:-morpheus}/media:/data		- /mnt/${MEDIA_POOL:-morpheus}/media:/data
Line 66:		Line 66:
	In docker compose, and probably docker below it, has a hierarchy where it looks for environment variables the docker uses itself or to pass through to the application. Docker will process the files defined by the env_file directive and then in the .env file in the directory where the docker-compose.yml file sits and then definitions in the environment section. It is important that the variables be defined before they are used.		In docker compose, and probably docker below it, has a hierarchy where it looks for environment variables the docker uses itself or to pass through to the application. Docker will process the files defined by the env_file directive and then in the .env file in the directory where the docker-compose.yml file sits and then definitions in the environment section. It is important that the variables be defined before they are used.

	Without getting too far into the weeds, all of the common variables are defined in a file that is picked up with the env_file directive. ~~I added the~~ environment section for ~~clarity~~. The ~~variables are actually defined~~ in the ~~common file~~.		Without getting too far into the weeds, all of the common variables are defined in a file that is picked up with the env_file directive. The environment section adds information that is important to this application.

			At volumes, it gets a little interesting. The definition is split by a ':' with the left part defining the external location and the right part defining where it will appear in the file layout where the application runs. The first definition is for tank. The ${APPS_POOL} variable points to the tank storage pool while the ${MEDIA_POOL} to the big bucket that holds the bulk of everything. The APPS_POOL is organized by the application and if you examine the directory layout in tank it follows a convention that includes the stack and container in the definition. The MEDIA_POOL really doesn't generally have an application focus. For example, several applications all work with video files.

Lynn: /* Incorporating the docker-compose.yml file into the stack */

2026-09-10T01:16:49Z

Incorporating the docker-compose.yml file into the stack

@@ Line 10: / Line 10: @@
 <pre>
 services:
-   ctroadmap:
+   weaver:
-     image: ghcr.io/noobcity99/ctroadmap:beta
+     image: ghcr.io/scryer-media/weaver:latest
-     container_name: ctroadmap-beta
+     container_name: weaver
      ports:
-       - "8088:8088"
+       - "9090:9090"
      volumes:
-       # Persistent atlas data and generated exports live beside this compose file.
+       - weaver-config:/config
-      - ./data:/app/data
+       - /path/to/downloads:/downloads
-       - ./exports:/app/exports
-    restart: unless-stopped
+volumes:
 </pre>
@@ Line 27: / Line 37: @@
 The volumes listed under the volumes directive almost always need to be modified. Proper definition here allows for data used by the application to be persistent. It also makes things easy to find and backup. It is most common for an application two have two volumes defined. The first is to store configuration data. Often some historical data is stored there along with modest databases. The storage pool, called tank, for all of this is 2TB so putting a large set of data there, even if it is only temporary, could create problems.

Lynn: /* Incorporating the docker-compose.yml file into the stack */

2026-09-10T00:47:00Z

Incorporating the docker-compose.yml file into the stack

← Older revision		Revision as of 00:47, 10 September 2026
Line 3:		Line 3:
	The purpose of having a test environment is to allow applications to be stood up and tested without disturbing the other applications in the group. I have tried to not add too many additional stacks to the original set, but the author's interests and mine diverge a little bit. Going forward, adding applications to a stack is done by adding a new stack with a number at the end. For example, adding applications to the admin stack is done with a new stack called admin2. An admin3 can be added so that the number of applications in a stack don't become unmanageable.		The purpose of having a test environment is to allow applications to be stood up and tested without disturbing the other applications in the group. I have tried to not add too many additional stacks to the original set, but the author's interests and mine diverge a little bit. Going forward, adding applications to a stack is done by adding a new stack with a number at the end. For example, adding applications to the admin stack is done with a new stack called admin2. An admin3 can be added so that the number of applications in a stack don't become unmanageable.

	===Incorporating the docker-compose.yml file into the stack===		====Incorporating the docker-compose.yml file into the stack====
			Docker compose is a great tool for managing stacks of individual services. It is a definite improvement from having a shell script with a bunch of docker run commands in it. Further improvement comes from the addition of the dockge and dockhand tools. These two applications are different approaches to managing the stacks. For the sake of discussion, stacks contain containers and containers contain images. An image, while defined in a single line, cans contain a number of images.

			A docker compose file will start out looking a lot like this one:

			<pre>
			services:
			ctroadmap:
			image: ghcr.io/noobcity99/ctroadmap:beta
			container_name: ctroadmap-beta
			ports:
			- "8088:8088"
			volumes:
			# Persistent atlas data and generated exports live beside this compose file.
			- ./data:/app/data
			- ./exports:/app/exports
			restart: unless-stopped
			</pre>

			There are other directives, but this one is typical. The indentation levels are important and it assumed that lines at the same indentation level are linked together. Generally, the order of lines at the same group and level don't matter. The very first line that you see under services defines how the container will be identified on from the outside. The container_name directive is usually have the same name, but not always.

			Since the order is a bit of a free for all, I like to regularize the declaration order and there are a few additions that I put in whether I need them or not.

			The volumes listed under the volumes directive almost always need to be modified. Proper definition here allows for data used by the application to be persistent. It also makes things easy to find and backup. It is most common for an application two have two volumes defined. The first is to store configuration data. Often some historical data is stored there along with modest databases. The storage pool, called tank, for all of this is 2TB so putting a large set of data there, even if it is only temporary, could create problems.

Lynn: /* Adding and naming stacks */

2026-09-10T00:19:04Z

Adding and naming stacks

← Older revision		Revision as of 00:19, 10 September 2026
Line 1:		Line 1:
	==Setting up an application in the test environment==		==Setting up an application in the test environment==
	===Adding and naming stacks===		====Adding and naming stacks====
	The purpose of having a test environment is to allow applications to be stood up and tested without disturbing the other applications in the group. I have tried to not add too many additional stacks to the original set, but the author's interests and mine diverge a little bit. Going forward, adding applications to a stack is done by adding a new stack with a number at the end. For example, adding applications to the admin stack is done with a new stack called admin2. An admin3 can be added so that the number of applications in a stack don't become unmanageable.		The purpose of having a test environment is to allow applications to be stood up and tested without disturbing the other applications in the group. I have tried to not add too many additional stacks to the original set, but the author's interests and mine diverge a little bit. Going forward, adding applications to a stack is done by adding a new stack with a number at the end. For example, adding applications to the admin stack is done with a new stack called admin2. An admin3 can be added so that the number of applications in a stack don't become unmanageable.

	===Incorporating the docker-compose.yml file into the stack===		===Incorporating the docker-compose.yml file into the stack===

Lynn: Created page with "==Setting up an application in the test environment== ===Adding and naming stacks=== The purpose of having a test environment is to allow applications to be stood up and tested without disturbing the other applications in the group. I have tried to not add too many additional stacks to the original set, but the author's interests and mine diverge a little bit. Going forward, adding applications to a stack is done by adding a new stack with a number at the end. For exampl..."

2026-09-10T00:18:45Z

Created page with "==Setting up an application in the test environment== ===Adding and naming stacks=== The purpose of having a test environment is to allow applications to be stood up and tested without disturbing the other applications in the group. I have tried to not add too many additional stacks to the original set, but the author's interests and mine diverge a little bit. Going forward, adding applications to a stack is done by adding a new stack with a number at the end. For exampl..."

New page

==Setting up an application in the test environment==
===Adding and naming stacks===
The purpose of having a test environment is to allow applications to be stood up and tested without disturbing the other applications in the group. I have tried to not add too many additional stacks to the original set, but the author's interests and mine diverge a little bit. Going forward, adding applications to a stack is done by adding a new stack with a number at the end. For example, adding applications to the admin stack is done with a new stack called admin2. An admin3 can be added so that the number of applications in a stack don't become unmanageable.
===Incorporating the docker-compose.yml file into the stack===