Absolutely, your setup idea is totally doable! Let me break down exactly how to make this work with GitLab CI since you're just getting started with it.

Your goal—triggering docker-compose down on two separate Docker servers (prod/dev) via code pushes or manual actions—is fully achievable with GitLab CI. The core idea is using GitLab Runners to execute commands directly on your target servers, paired with pipeline rules to control when those commands run.

1. Set Up GitLab Runners on Both Servers #

First, you need to install and register GitLab Runners on each server. These runners will act as the "hands" that run your docker-compose commands:

• Install GitLab Runner on both production and development servers (follow the standard GitLab installation steps for your OS)
• When registering each runner, assign unique tags: use prod-server for the production machine, dev-server for the dev machine. This lets your CI pipeline target the right server for each task.
• Grant Docker permissions to the runner user: Run usermod -aG docker gitlab-runner on each server, then restart the runner service. This ensures the runner can execute Docker commands without permission errors.

2. Write Your .gitlab-ci.yml Configuration #

Drop this file in your repo's root directory—it defines exactly when and how your services get stopped. Below are configurations for both your trigger scenarios:

Scenario 1: Trigger on Code Commit #

If you want to auto-stop services when code is pushed to specific branches (e.g., main for prod, dev for dev):

stages:
  - stop_services

stop_prod_services:
  stage: stop_services
  tags:
    - prod-server  # Targets the production runner
  rules:
    - if: $CI_COMMIT_BRANCH == 'main'  # Runs only when code is pushed to main
  script:
    - cd ./path/to/docker-compose-files  # Replace with your actual repo path (or skip if in root)
    - docker-compose down

stop_dev_services:
  stage: stop_services
  tags:
    - dev-server  # Targets the development runner
  rules:
    - if: $CI_COMMIT_BRANCH == 'dev'  # Runs only when code is pushed to dev
  script:
    - cd ./path/to/docker-compose-files
    - docker-compose down

Scenario 2: Manual Trigger (For Safe Production Control) #

If you prefer manual control (especially critical for production to avoid accidental outages), configure jobs to require a manual click in the GitLab UI:

stages:
  - stop_services

stop_prod_services_manual:
  stage: stop_services
  tags:
    - prod-server
  rules:
    - if: $CI_PIPELINE_SOURCE == 'web'  # Only runs when triggered manually via GitLab web UI
      when: manual
  script:
    - cd ./path/to/docker-compose-files
    - docker-compose down

stop_dev_services_manual:
  stage: stop_services
  tags:
    - dev-server
  rules:
    - if: $CI_PIPELINE_SOURCE == 'web'
      when: manual
  script:
    - cd ./path/to/docker-compose-files
    - docker-compose down

You can also mix these scenarios—e.g., auto-trigger dev services on code push, and keep production as manual-only—just adjust the rules section for each job.

3. Key Things to Double-Check #

• Path Accuracy: Make sure the cd path in your script matches where your docker-compose.yml lives in your repo. If it's in the root directory, you can skip the cd command entirely.
• Docker Compose Installation: Confirm both servers have docker-compose (or the newer docker compose CLI) installed and compatible with your config file.
• Production Safety: For production, stick to manual triggers unless you're 100% confident auto-stopping won't cause issues.

This setup will fully meet your requirements—you can trigger service stops either by pushing code to the right branches, or by manually kicking off the pipeline in GitLab.

内容的提问来源于stack exchange，提问作者mcode