# Поддержка Dockerfile для GitHub Actions

При создании Dockerfile для действия контейнера Docker следует знать, как отдельные инструкции Docker взаимодействуют с GitHub Actions и файлом метаданных действия.

> \[!NOTE]
> GitHub Enterprise Serverразмещенные в данный момент средства выполнения не поддерживаются в GitHub.

### Пользователь

Действия Docker должен выполнять пользователь Docker по умолчанию (корневой). Не используйте инструкцию `USER` в вашем `Dockerfile`каталоге, так как вы не сможете получить доступ к каталогу `GITHUB_WORKSPACE` . Дополнительные сведения см\[. в справочнике[ ПО AUTOTITLE](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/variables#default-environment-variables) и ]\(<https://docs.docker.com/engine/reference/builder/#user)USER> в документации По Docker.

### FROM

Первой инструкцией в `Dockerfile` должна быть `FROM`, выбирающая базовый образ Docker. Дополнительные сведения см. в [справочнике FROM](https://docs.docker.com/engine/reference/builder/#from) в документации по Docker.

Далее приведены некоторые рекомендации по настройке аргумента `FROM`:

* Рекомендуется использовать официальные образы Docker. Например, `python` или `ruby`.
* Используйте тег версии (если он существует), предпочтительно с основным номером версии. Например, используйте функцию `node:10` вместо `node:latest`.
* Рекомендуется использовать образы Docker, основанные на операционной системе [Debian](https://www.debian.org/).

### WORKDIR

GitHub задает путь к рабочему каталогу в переменной `GITHUB_WORKSPACE` среды. Инструкцию `WORKDIR` не рекомендуется использовать в `Dockerfile`. Перед выполнением GitHub действия подключите `GITHUB_WORKSPACE` каталог на вершине всего, что было в этом расположении в образе Docker и задайте `GITHUB_WORKSPACE` в качестве рабочего каталога. Дополнительные сведения см. в статье [Справочник по переменным](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/variables#default-environment-variables) и [справочнике](https://docs.docker.com/engine/reference/builder/#workdir) ПО WORKDIR в документации по Docker.

### ENTRYPOINT

Если вы укажите `entrypoint` в файле метаданных действия, он переопределит `ENTRYPOINT`, указанный в файле `Dockerfile`. Дополнительные сведения см. в разделе [Справочник по синтаксису метаданных](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/metadata-syntax#runsentrypoint).

Инструкция Docker `ENTRYPOINT` имеет форму *оболочки* и форму *exec*. В документации по `ENTRYPOINT` Docker рекомендуется использовать форму *exec* инструкции `ENTRYPOINT`. Дополнительные сведения о форме *exec* и форме *оболочки* см. в [справочнике ENTRYPOINT](https://docs.docker.com/engine/reference/builder/#entrypoint) в документации по Docker.

Не следует применять `WORKDIR` для указания точки входа в Dockerfile. Вместо этого воспользуйтесь абсолютным путем. Дополнительные сведения см. в статье о [WORKDIR](#workdir).

Если вы настроите контейнер для использования формы *exec* инструкции `ENTRYPOINT`, `args`, настроенный в файле метаданных действия, не будет выполняться в командной оболочке. Если `args` действия содержит переменную среды, эта переменная не будет заменена. Например, при использовании следующего формата *exec* вместо значения, хранящегося в `$GITHUB_SHA`, будет напечатано `"$GITHUB_SHA"`.

```dockerfile
ENTRYPOINT ["echo $GITHUB_SHA"]
```

Если вам нужно выполнить подстановку переменной, используйте форму *оболочки* или выполните оболочку напрямую. Например, используя следующий формат *exec*, можно выполнить оболочку для печати значения, хранящегося в переменной среды `GITHUB_SHA`.

```dockerfile
ENTRYPOINT ["sh", "-c", "echo $GITHUB_SHA"]
```

Чтобы предоставить `args`, определенный в файле метаданных действия, контейнеру Docker, который использует форму *exec* в `ENTRYPOINT`, рекомендуется создать сценарий оболочки под именем `entrypoint.sh`, вызываемый из инструкции `ENTRYPOINT`:

#### Пример *Dockerfile*

```dockerfile
# Container image that runs your code
FROM debian:9.5-slim

# Copies your code file from your action repository to the filesystem path `/` of the container
COPY entrypoint.sh /entrypoint.sh

# Executes `entrypoint.sh` when the Docker container starts up
ENTRYPOINT ["/entrypoint.sh"]
```

#### Пример файла *entrypoint.sh*

Используя приведенный выше пример Dockerfile, GitHub отправит настроенный `args` в файле метаданных действия в качестве аргументов `entrypoint.sh`. Добавьте `#!/bin/sh`[shebang](https://en.wikipedia.org/wiki/Shebang_\(Unix\)) в начало файла `entrypoint.sh`, чтобы явно использовать оболочку, соответствующую [POSIX](https://en.wikipedia.org/wiki/POSIX).

```shell
#!/bin/sh

# `$#` expands to the number of arguments and `$@` expands to the supplied `args`
printf '%d args:' "$#"
printf " '%s'" "$@"
printf '\n'
```

Ваш код должен быть исполняемым. Прежде чем использовать файл `entrypoint.sh` в рабочем процессе, убедитесь, что он имеет разрешения `execute`. Вы можете изменить разрешение в терминале с помощью следующей команды:

```shell
chmod +x entrypoint.sh
```

Если сценарий оболочки `ENTRYPOINT` не является исполняемым, вы получите следующую ошибку:

```shell
Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"/entrypoint.sh\": permission denied": unknown
```

### CMD

Если вы определите `args` в файле метаданных действия, `args` переопределит инструкцию `CMD`, указанную в `Dockerfile`. Дополнительные сведения см. в разделе [Справочник по синтаксису метаданных](/ru/enterprise-server@3.22/actions/reference/workflows-and-actions/metadata-syntax#runsargs).

При использовании `CMD` в своем `Dockerfile` следуйте приведенным ниже рекомендациям:

1. Задокументируйте обязательные аргументы в README действия и опустите их из инструкции `CMD`.
2. Используйте значения по умолчанию, позволяющие использовать действие без указания `args`.
3. Если действие предоставляет флаг `--help` или что-то подобное, используйте его, чтобы действие документировало само себя.

## Поддерживаемые возможности Linux

GitHub Actions поддерживает возможности Linux по умолчанию, поддерживаемые Docker. Возможности нельзя добавлять или удалять. Дополнительные сведения о возможностях Linux по умолчанию, поддерживаемых Docker, см[](https://docs.docker.com/engine/security/#linux-kernel-capabilities). в документации по Docker. Дополнительные сведения о возможностях Linux см. в разделе ["Общие сведения о возможностях](http://man7.org/linux/man-pages/man7/capabilities.7.html) Linux" на страницах "Человек" в Linux.