external_url 'https://gitlab.mydomain.com'
nginx['listen_port'] = 80
nginx['listen_https'] = false
nginx['proxy_set_headers'] = {
"Host" => "$http_host_with_default",
"X-Real-IP" => "$remote_addr",
"X-Forwarded-For" => "$proxy_add_x_forwarded_for",
"X-Forwarded-Proto" => "https",
"X-Forwarded-Ssl" => "on",
"Upgrade" => "$http_upgrade",
"Connection" => "$connection_upgrade"
}ports:
- '8080:80'
- '2022:22'proxy_pass http://gitlab:8080;
Dockerfile добавляется слой с ssmtp и всё. В качестве ENTRYPOINT небольшой sh-скрипт, который конфигурирует sssmtp при старте контейнера в зависимости от переменных окружения. Все письма пересылаются на внешний центральный Postfix, который уже крутит всю бодягу с DKIM подписями и прочими email-прибамбасами.docker-compose.yml:version: '3'
services:
fpm:
container_name: fpm
image: my/app
depends_on:
- mailserver
expose:
- "9000" # php-fpm
environment:
- SMTP_SERVER=mailserver:587
- SMTP_USER=testing@moderation.test
- SMTP_PASSWORD=qweqweqwe
nginx:
container_name: nginx
image: nginx:stable-alpine
depends_on:
- fpm
ports:
- "80:80" # http
volumes:
- .dev/nginx.vhost.conf:/etc/nginx/conf.d/default.conf:ro
mailserver:
container_name: mailserver
image: tvial/docker-mailserver:v2
hostname: mail
domainname: mydomain.test
ports:
- "25:25" # smtp
- "143:143" # imap
- "587:587" # smtp-auth
- "993:993" # imap-secure
volumes:
- .dev/mail/accounts.cf:/tmp/docker-mailserver/postfix-accounts.cf:roЯ понимаю что ядро одно, но окружение слишком разнообразное, мне нужна одна система.
Как использование кучи дистрибутивов скажется на производительности, если она очень важна вопреки удобству?
mysqld, то какие там файлы остальные в контейнере лежат - по-барабану, потому что производительность mysqld зависит от него самого, его конфигурации, и ресурсов машины, а не от того, по чьему фэн-шую разложены файлы, CentOS'овскому, или Debian'овскому.
9001.xdebug.remote_port=9001expose.expose:
- "9000"
- "9001"docker-compose.yml.Expose ports without publishing them to the host machine - they’ll only be accessible to linked services.
docker-compose.yml не видно, а значит он и не может видеть Xdebug на том порту, что Вы ему скармливаете.9001 в ports:.Host: localhost для Xdebug (сейчас у Вас там какой-то левый IP).
--network=host.
# Install Xdebug
RUN apk add --update --no-cache --virtual .tools-deps \
autoconf g++ libtool make \
&& (yes | pecl install xdebug) \
&& apk del .tools-deps \
&& rm -rf /var/cache/apk/*sudo systemctl enable docker-project.serviceExecStart'ом будет стартовать один контейнер через docker run, что связка контейнеров через docker-compose up, для systemd и CoreOS принципиальной разницы нет.[Unit] есть следующие строки:Requires=docker-project.service
After=docker-project.servicedocker-project.service. Но, насколько я понимаю из Вашего описания, это и есть декларация docker-project.service. То есть Вы говорите systemd что сервис должен быть запущен после запуска самого себя. Это не есть гуд. Эти строки, судя по всему, должны быть такими:Requires=docker.service
After=docker.servicedocker-up.sh у Вас docker-compose up запускается в foreground'е. Первая связка контейнеров то запустится, а что со второй - не понятно. Наверное, все же стоило их запускать с -d ключиком, а в systemd декларации в секции [Service] указать Type=forking, если прям так нужно обе связки контейнеров запускать одним systemd service. Но вообще, имхо, на каждый docker-compose.yml должен быть свой отдельный systemd service, и никаких forking.docker-compose команды внутрь docker-up.sh было не самой хорошей идеей. Вам ничего не мешало написать несколько ExecStart'ов подряд, тем самым не размазывая декларацию по нескольким файлам, и было бы видно на каком именно шаге оно отваливается при systemctl start docker-project.service.journalctl --unit=docker-project.service дабы глянуть что там вообще произошло, и кто на кого ругается.
docker run --rm -it -v $(pwd)/test.py:/test.py:ro python python34 /test.pyphp composer.phar install выполняется от имени root внутри контейнера, то примерно следующие строки должны быть в `docker-compose.yml`:version: '2'
services:
php:
...
volumes:
...
- /path/to/my.key:/root/.ssh/repo.key:ro
...
...docker - это консольный интерфейс (CLI) для работы с Dockerdocker build создает по заданному Dockerfile образ контейнераdocker tag присваивает указанному образу указанный тег (опция -t для build делает то же самое)docker pull скачивает указанный образ из удаленного регистра на текущую машинуdocker push заливает указанный образ в удаленный регистрdocker run запускает новый контейнер из указанного образаdocker ps выводит список текущих "бегущих" контейнеровdocker не жонглирует файлами, она жонглирует образами и контейнерами, а они от нас абстрагированы Docker'ом, как что-то эфемерное. То есть выполняя комманду docker pull Вы не скачиваете образ в ту папку, где выполняете команду, и уж точно не скачиваете какие-либо файлы. Все что Вы делаете этой командой - это скачиваете образ в локальное хранилище Docker'а, дабы Docker daemon мог запустить контейнер на основании этого образа.docker-compose - это уже совсем другая команда. Все что она делает - это читает указанный YAML-манифест и выполняет соответствующие команды Docker. Это всего лишь позволяет декларативно указывать желаемые сценарии при работе с Docker в удобном формате. Но ни команда docker, ни docker-compose, не предоставляют ничего для того, чтобы транспортировать/обновлять версии Ваших манифестов где-то там. Docker, опять таки, жонглирует образами и контейнерами, не более.build:. Таким образом docker-compose пытается сначала собрать контейнер, вместо того, чтобы просто запустить его из образа.docker-compose.yml под каждый env, все правильно советовали. Именно так это и задумывалось. Вы в манифесте указываете отнюдь не разные окружения (development, production), а набор контейнеров, которые должны бежать в одной связке одной логической единицей (концепция POD'ов). Ничего не запрещает делать и так, как сделали Вы, но это сродни использованию дуршлага в роли миски для еды: сегодня Вы нормально из него наворачиваете пельмени, а завтра супчик в нем уже куда-то не туда утекает.docker-compose.yml, согласно которому контейнер перед запуском собирается из сорцов.docker build, присваиваете ему номер версии через docker tag и отправляете в удаленный регистр образов через docker push.docker-compose.ymlв котором указано запускать конкретную версию образа (и никаких build). Новая версия приложения - меняем тег образа в манифесте и перезапускаем контейнеры. При выполнении docker-compose образ автоматически скачается перед запуском, если его нет локально. Если же Вы обновили образ конкретной версии, которая уже была скачана ранее, то да, нужно выполнить docker pull перед стартом, дабы скачать новый образ.
CMD в Dockerfile). Так, например, 7.0-fpm образ представляет собой процесс php-fpm демона. А вот 7.0-cli это просто запуск php-интерпретатора в интерактивном режиме (php -a). Версия 7.0-apache вообще являет собою Apache сервер, который умеет запускать php-скрипты.apache и вяжем с контейнером php:fpm. Если Вам нужно, чтобы Apache напрямую запускал php-скрипты, берем один контейнер php:apache.
megacopy комманду в задачник cron'а и запустите crond главным процессом контейнера (чтобы бежал в foreground).
docker-daemon - это HTTP-сервер и он может взять на себя это работу на стороне сервера, т.е. nginx не нужен
docker на дев-машине можно (как-то) связать с докером на хостинге
и учитвыая предудущий пункт - docker можно использовать для деплоя
docker можно использовать для отката, если деплой не задался
пропадает необходимость в во всяких rbenv и pyenv, если нужна другая версия языка, то просто создается новый контейнер в котором и происходит установка
докер очень быстрый, в т.ч. старты и рестарты