Skip to content

Latest commit

 

History

History
134 lines (90 loc) · 5.33 KB

create-your-first-gipops-compose-file.md

File metadata and controls

134 lines (90 loc) · 5.33 KB

Create your first GipOps Compose file

Time Required30 Minutes
DifficultyLow

Create your first Compose file

In this example, we're going to massage the LinuxServer.io's Ombi image to match our best practices, per below

Create your Compose file

  1. Open your GitHub repo and enter the docker-compose folder

  2. Click on 'Add file' > 'Create new file'

  3. Name the file 'ombi.yml', and copy the compose file from here
    It should look something like this:

  4. Refer to the best practices and tips documentation below and edit the file

  5. Hit 'Commit changes...'

  6. hit 'Commit changes'

Oh, you want me to give you the answer to step 4?

As of writing, here is the ombi.yml compose file

---
version: "2.1"
services:
  ombi:
    image: lscr.io/linuxserver/ombi:latest
    container_name: ombi
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - BASE_URL=/ombi #optional
    volumes:
      - /path/to/appdata/config:/config
    ports:
      - 3579:3579
    restart: unless-stopped

Here is my tweaked file

---
version: "2.1"
services:
  ombi:
    image: ghcr.io/linuxserver/ombi:4.39.1
    #container_name: ombi
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=$TZ
      - BASE_URL=/$BASE_URL #optional
    volumes:
      - config:/config
    ports:
      - $PORT_HTTP:3579
    restart: unless-stopped
volumes:
  config:

Best Practices and tips

Variables

To keep your compose files as system agnostic as possible, its best to use variables where you can. Some suggestions are

  • Ports (eg $HTTP_PORT, $DB_PORT, $API_PORT)
  • Mounted volumes (eg $CONFIG, $DATA)
  • Timezones (eg $TZ)

These variables can then be set in Portainer when creating the stack

Don't name containers unless there is a requirement for it

Some compose files may name a database 'db', which will then block you from using that name anywhere else. Its best to let Portainer manage names of containers.

Container Image versioning

Do not use the 'latest' tag, as it does not allow Renovate to update the compose file

When versioning your compose files, locate the 'latest' tag on the DockerHub, GitHub etc and use the relevant version number.

This is harder to do on DockerHub. Per the screenshot below, we've located the 'tatest' tag and used the Digest to locate the correct version.

Take note of the OS/ARCH as well - you can see that tag 2.12.5 contains both AMD64 and ARM64 containers, meaning this compose file can be used on both ARM and x86 machines.

Container Image locations

As Docker has now started rate limiting non-paying users, a lot of container creators are putting their containers on GitHub or other services

Its quite easy to figure out if a container exists on GitHub;

  1. If the 'Packages' option exists, the container is on GitHub\

  2. The container URL is underlined\