Portainer Example

[JTHesse]

Hi there, I would like to run the services in portainer as a stack. Does anyone already have an example stack. I'm unsure how to handle the profiles in portainer. Thank you!

[telekineticyeti]

Here is the stack config I use for portainer:

version: '3.9'

x-base_service: &base_service
    ports:
      - "${WEBUI_PORT:-7860}:7860"
    volumes:
      - &v1 stable-diffusion-data:/data
      - &v2 stable-diffusion-output:/output
    stop_signal: SIGKILL
    tty: true
    deploy:
      resources:
        reservations:
          devices:
              - driver: nvidia
                device_ids: ['0']
                capabilities: [compute, utility]

name: webui-docker

services:
  download:
    build: https://github.com/AbdBarho/stable-diffusion-webui-docker.git#:/services/download
    profiles: ["download"]
    volumes:
      - *v1

  auto: &automatic
    <<: *base_service
    profiles: ["auto"]
    build: https://github.com/AbdBarho/stable-diffusion-webui-docker.git#:/services/AUTOMATIC1111
    image: sd-auto:74
    environment:
      - CLI_ARGS=--allow-code --xformers --enable-insecure-extension-access --api

  auto-cpu:
    <<: *automatic
    profiles: ["auto-cpu"]
    deploy: {}
    environment:
      - CLI_ARGS=--no-half --precision full --allow-code --enable-insecure-extension-access --api

  invoke: &invoke
    <<: *base_service
    profiles: ["invoke"]
    build: https://github.com/AbdBarho/stable-diffusion-webui-docker.git#:/services/invoke/
    image: sd-invoke:30
    environment:
      - PRELOAD=true
      - CLI_ARGS=--xformers

  # invoke-cpu:
  #   <<: *invoke
  #   profiles: ["invoke-cpu"]
  #   environment:
  #     - PRELOAD=true
  #     - CLI_ARGS=--always_use_cpu

  comfy: &comfy
    <<: *base_service
    profiles: ["comfy"]
    build: https://github.com/AbdBarho/stable-diffusion-webui-docker.git#:/services/comfy/
    image: sd-comfy:6
    environment:
      - CLI_ARGS=

  comfy-cpu:
    <<: *comfy
    profiles: ["comfy-cpu"]
    deploy: {}
    environment:
      - CLI_ARGS=--cpu

volumes:
  stable-diffusion-data:
    external: true
  stable-diffusion-output:
    external: true

Since we're using portainer, working with relative paths is kind of a pain, so I've modified the build properties for each profile to set the build context to a sub-path of the stable-diffusion-webui-docker git repository URL.

To initiate profiles in portainer, you need to create an environment variable called 'COMPOSE_PROFILES', with the value set to the profile name you want to run. Example, setting the value to download and running the stack, will install assets:

When that profile completes the container will terminate. When that happens, set the COMPOSE_PROFILES value to the tool you want to use (e.g. auto), and start the stack again:

Hope that helps!

[JTHesse]

Hi @telekineticyeti , thank you very much for your extensive answer. Unfortunately, I just figured that we are using docker swarm and therefore profiles and the usage of git URLs are not available.

[DevilaN]

What's wrong with Docker Swarm? I am running both Swarm and Portainer on regular basis, and can't think what could be here a problem.

[JTHesse]

Portainer keeps saying "Additional property profiles is not allowed" maybe Portainer is configured differently.

[JTHesse]

Also I think "build" is not supported by swarm.

[DevilaN]

Swarm is dedicated to deploy things, not to build them.
You still need multiple step process here, like:

1. Overriden image names in docker-compose.override.yml that are pointing to your private docker registry.
2. Git hook that builds image each time you pull new commits for repo. Then it pushes that image to registry.
3. Separate docker-compose.yml only for deploying purposes, written by you to work with swarm.
4. Additional swarm service that monitors registry and redeploy service when there is new image.

Profiles are meant to be used to separate parts of stack and run only "production" or "development" apps locally.
In most use cases you don't want to have profiles in your swarm stack. If you need to control which services should run then you can do it simply modifying entrypoint and bind mounting file that states which service should be running so you can use this file contents on modified command for service to exit early if it's not it's name. Then there is another service that monitors changes in this file, and if you change it's contents, then by inotify there should be event fired and handled so all services restarts (and then all of them reads that file, so only selected one will not exit and work).
Probably you need another service that allows to post form that will allow to choose which of auto / comfy / something else should be running and after receiving info it will change contents of file used to notify / run specific services.

A bit of work, but doable.

[telekineticyeti]

I'm not familiar with working with swarm but for what it's worth, I have an additional process that I have used before. It's a few extra steps but it may be compatible with your needs:

• Use the main compose profile above to build and start the containers locally, or on a non-swarm environment
• Retag the sd-auto:74 container and push it to a private docker registry

Then use a straight-forward compose-profile that pulls the image from your registry and launches without profile:

version: '3.9'

services:
  automatic1111:
    container_name: automatic1111
    image: my.registry/automatic1111:1.8
    ports:
      - "${WEBUI_PORT:-7860}:7860"
    volumes:
      - &v1 stable-diffusion-data:/data
      - &v2 stable-diffusion-output:/output
    stop_signal: SIGKILL
    tty: true
    environment:
      - CLI_ARGS=--allow-code --xformers --enable-insecure-extension-access --api
    deploy:
      resources:
        reservations:
          devices:
              - driver: nvidia
                device_ids: ['0']
                capabilities: [compute, utility]

volumes:
  stable-diffusion-data:
    external: true
  stable-diffusion-output:
    external: true