Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clean up and create templates for apps #34

Open
jaredballou opened this issue Aug 6, 2023 · 3 comments
Open

Clean up and create templates for apps #34

jaredballou opened this issue Aug 6, 2023 · 3 comments

Comments

@jaredballou
Copy link

Hi, I was going to add a new service to my local instance, but when looking at how to add it to the Python code I realized that there's a lot of room for improvement on the way configs are generated and parsed to create the docker-compose file.

I was curious if you'd have any interest in moving to something that uses a smaller config file to define apps/containers/env vars and other settings, and generalize the processor to output the final yaml from that, rather than having large chunks of static text that get parsed and merged.

It's not a ton of work, I can probably do a lot of the basic YAML editing and stake out an MVP for this over a few evenings, but I'm not sure if you'd want to go that route, so I figured I'd ask before I spend six hours coding something nobody else will use :)

Thanks for the project though, I've definitely gotten my money's worth out of it.

@Luctia
Copy link
Owner

Luctia commented Aug 8, 2023

That sounds interesting! I'm always up for improvements, I'm curious what you have in mind. If you want to, you could give a small example (before/after) before you really get started, but this already sounds good to me.

@jaredballou
Copy link
Author

Sure, so for starters there would be a single 'master' docker-compose data source, I think the easiest is to simply have it be a regular docker-compose.yml which includes all services, and then ingest/transform/export from there. This would replace the current container_configs commands with operations on the ingested YAML data which now is an OrderedDict, simplifying the generation and giving a better methodology to do data manipulation without so much repetitive static text strings.

The other big change will be to have a section in the docker-compose file which defines all the core settings, and use includes to reference the definitions which are now shared and defined in one place, making it easier to connect services together and manage things like uid/gid/path mappings.

The last thing would be an 'overrides' YAML file, which would allow tweaking and setting per-app variables without requiring users to go through the whole base config (and also allowing changes without creating potential conflicts when users want to pull changes without erasing their local customization).

I can whip up a branch to wireframe the basic functionality and have a couple functions to show how it'd work, and so you can visualize how the pieces fit, if that sounds good to you.

@LucasFA
Copy link

LucasFA commented Jun 5, 2024

FWIW I have a common.yml file with

services:
  mediacenter_service:
    environment:
      - PGID=13000
      - UMASK=002
      - TZ=Europe/Amsterdam # This is what is currently used, but I personally instead mount localtime as I use Linux:
    volumes:
      - /etc/localtime:/etc/localtime:ro
    restart: unless-stopped

And then each service goes something like:

services:
  sonarr:
    extends:
      file: common.yml
      service: mediacenter_service
    image: lscr.io/linuxserver/sonarr:latest
    container_name: sonarr
    environment:
      - PUID=13001
    volumes:
      - some/path:other/path
      - /some/other/path:/also/path
    ports:
      - "xyze:xyze"

which is not shorter in LOC terms but reduces each service declaration to volumes, ports and PUID, getting rid of the timezone, restart, PGID and UMASK fields.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants