Как хост может определить местоположение сборки Jenkins?

Как лучше автоматизировать процесс сборки приложения, используя Jenkins в Docker, если исходный код размещен на Git-ресурсе? У меня установлены только Docker и нет средств оркестрации. Задача состоит в том, чтобы собрать проект из исходников и поместить его в Docker-контейнер. Я изучил документацию и обнаружил, что существуют два способа работы Jenkins через Docker, один из которых включает использование sshagent, а другой - Jenkins с параметрами DinD. Как правильно организовать файл docker-compose.yml, чтобы избежать избыточности и эффективно настроить оба этих подхода?
  • 22 октября 2024 г. 19:42
Ответы на вопрос 2
Для решения задачи автоматизации процесса сборки приложения с помощью Jenkins в Docker, где исходный код размещен на Git-ресурсе, вам потребуется настроить Jenkins в контейнере Docker и правильным образом организовать файл `docker-compose.yml`, чтобы минимизировать избыточность и упростить процесс.

### 1. Определение местоположения сборки Jenkins

Jenkins может определить местоположение сборки по нескольким параметрам:
- **Job Configuration**: В интерфейсе Jenkins в настройках каждой задачи указано, где брать исходный код (например, URL репозитория Git).
- **Workspace**: Jenkins создает специальное пространство (workspace) для каждой задачи, где и происходит сборка. Путь к workspace можно узнать из конфигурации Jenkins.

### 2. Automaция сборки с помощью Jenkins в Docker

Для развертывания Jenkins в Docker можно использовать `docker-compose`. В вашем случае, если вы хотите использовать как `sshagent`, так и `DinD` (Docker-in-Docker), вам нужно правильно настроить Dockerfile и `docker-compose.yml`.

### Пример `docker-compose.yml`

```yaml
version: '3.8'

services:
  jenkins:
    image: jenkins/jenkins:lts
    container_name: jenkins
    ports:
      - "8080:8080"
      - "50000:50000"
    volumes:
      - jenkins_home:/var/jenkins_home
      - /var/run/docker.sock:/var/run/docker.sock # Для DinD
    environment:
      JENKINS_OPTS: --httpPort=8080
    networks:
      - jenkins_network
  
  docker:
    image: docker:latest
    container_name: docker
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    networks:
      - jenkins_network

volumes:
  jenkins_home:
  
networks:
  jenkins_network:
```

### Пояснение:

1. **Jenkins Service**:
   - Используется официальный образ Jenkins (долгосрочная версия).
   - Порты для доступа к серверу Jenkins.
   - Монтируется volume для сохранения данных Jenkins.
   - `docker.sock` монтируется, чтобы Jenkins мог управлять контейнерами Docker.

2. **Docker Service**:
   - Этот сервис может быть полезен, если вам нужно выполнять дополнительные команды Docker в одном месте.
   - Также монтирует `docker.sock`, чтобы иметь доступ к Docker-демону.

### Использование sshagent и DinD

- **sshagent**: Этот подход необходим, если вам нужно управлять защищенными репозиториями, предполагая, что у вас есть SSH-ключи.
- **DinD**: Используется, если вы хотите запускать Docker внутри Docker-контейнера, что может быть полезно во время сборки.

#### Настройка Jenkins для использования этих подходов:

1. Для использования `sshagent`, установите соответствующий плагин в Jenkins и добавьте нужный SSH-ключ в настройки Credentials.
2. Для `DinD` вам нужно добавить в ваш Jenkins Pipeline шаги на основе Docker, чтобы строить образы и запускать контейнеры.

### Пример Jenkins Pipeline Script:

```groovy
pipeline {
    agent any
    stages {
        stage('Clone') {
            steps {
                git 'https://github.com/your-repo.git'
            }
        }
        stage('Build Docker image') {
            steps {
                script {
                    docker.build('your-image-name')
                }
            }
        }
    }
}
```

### Заключение

С помощью такого подхода вы сможете автоматизировать процесс сборки вашего приложения на Jenkins, используя Docker. Правильная настройка `docker-compose.yml` позволит вам избежать избыточности и максимально эффективно использовать возможности Jenkins и Docker.
Или технология эта все еще сырая.

Jenkins не сырая, а седая - 15 лет назад контейнеры не использовали. Я не использовал jenkins последние 4-5 лет, sshagent действительно выглядит некрасиво тут.

И стоит на что-то другое посмотреть?

Если можно использовать, то Github Actions, или другое "облачное" решение - тогда не нужно поднимать/конфигурировать build environment.
Похожие вопросы