сначала решите- что есть ваш артифакт

в идеале артифакт в концеплции контейнеров - контейнер

сначала решите- что есть ваш артифакт

Получается если говорить о сайтиках то артифактов 2. 1) Собранный фронт 2) Собранный бек оба представляют из себя просто пачку файлов.

в идеале - нет

для начала - возможно

А как в идеале? Архивы?

вы должны стремиться к тому, чтобы ваш backend был образом: <proj_name>_backend:latest

и через docker-registry деплоиться на стенд

Да, я вроде как этого и хочу. Просто не совсем понимаю что класть в этот образ кроме кода. Пыха отдельный контейнер, nginx тоже.

нет

контейнер = процесс

какой процесс выпоняет ваш код?

для java = jre

для js = вебсервер (apache2, nginx...)

для пхп = php-fpm/ новый nginx

какой процесс выпоняет ваш код?

никакого) Это просто набор php скриптов которые выполняются в контейнере php-fpm при запросе от контенера nginx

ну вот и экврика у вас есть контейнер с php-fpm

Вот вроде как и да, а вроде как и нет. Если у меня будет 10 сайтов, зачем плодить пыху?

потому что это 10 сервисов

модульность как соблюдать?

разные версии fpm как использовать?

ну да. Зачем мне 10 процессов пыхи если все сайты могут работать на одной

зачем вам виртуалки и контейнеры? Когда можно все запустить на одной железке?

зачем мне 10 процессов пыхи, если можно просто не юзать пыху

зачем мне 10 процессов пыхи, если можно просто не юзать пыху

а ты хорош)))

зачем мне 10 процессов пыхи, если можно просто не юзать пыху

дада и поставить линукс и тд и тп. Не об этом сейчас)

ыы

зачем вам виртуалки и контейнеры? Когда можно все запустить на одной железке?

Потому что есть еще и джава и питон. И весь этот зоопарк хочется оч быстро катать между окружениями

у пайтона есть virt-env

у java есть спринг

катай - не хочу

у пайтона есть virt-env

Есть но это не про бинарные либы. Туда только питонячьи ставятся.

у java есть спринг

А спринг чего? У нас кластер спарка, спринг тут не особо поможет)

еще раз - в идеале один процесс - один контейнер

один сайт = один процесс

а так можно и слона как мартышку на дерево втащить

но зачем?

Да согласен в принципе. Вот и хочу понять, надо оно мне или нет. Понятно что тем же ансиблом это все можно зарешать.

Вот смотрите, один сайт = один процесс. Но сайт состоит из фронта и бека. Которые собираются по разному и лежат в разных местах. По нормальному мне бы надо фронт монтировать напрямую в nginx, а бек в пыху. Это ок?

Вот смотрите, один сайт = один процесс. Но сайт состоит из фронта и бека. Которые собираются по разному и лежат в разных местах. По нормальному мне бы надо фронт монтировать напрямую в nginx, а бек в пыху. Это ок?

сайт не состоит из фронта и бэка

сервис мб

но не сайт

Ребят, всем привет. Скажите, а как по канонам докера собирать php сайтики? По сути какие есть компоненты: 1) PHP код бека 2) html/css/js и вот это вот всё для фронта 3) php-fpm 4) nginx 5) База Исходя из логики 1 процесс 1 контейнер, мне надо: 1) Volume для кода 2) Контейнер с php-fpm 3) Контейнер с nginx 4) Контейнер с базой И вроде как все логично, но не редко вижу когда php суют вместе с кодом в один контейнер. А иногда еще и базу к ним селят. Хотелось бы мнения послушать.

я вот тоже неверно сначала трактовал "1 процесс = 1 контейнер", пытался распихать php-fpm, nginx, app в разные контейнеры Но суть в том что я собираю сразу несколько микросервисов. api-gateway |--service1 |--service2 |--service3 |--serviceN Пытаясь собрать все это с минимально атомарной единицей, думал что меня заберут в дурку. В итоге допер что 1 целый микросервис , это 1 контейнер, чтобы он мог работать полностью автономно. Фронт так же отдельно как самодостаточный сервис. Наверно в архитектуре тут надо придерживатся такой логики: Строить микросервисы так, чтобы удалив любой, все остальные могли продолжать работать.

я вот тоже неверно сначала трактовал "1 процесс = 1 контейнер", пытался распихать php-fpm, nginx, app в разные контейнеры Но суть в том что я собираю сразу несколько микросервисов. api-gateway |--service1 |--service2 |--service3 |--serviceN Пытаясь собрать все это с минимально атомарной единицей, думал что меня заберут в дурку. В итоге допер что 1 целый микросервис , это 1 контейнер, чтобы он мог работать полностью автономно. Фронт так же отдельно как самодостаточный сервис. Наверно в архитектуре тут надо придерживатся такой логики: Строить микросервисы так, чтобы удалив любой, все остальные могли продолжать работать.

именно

как мне например разделить проект таким образом, чтобы 20 разработчиков могли независимо пилить 20 разных его кусочков

на сайт это ложится ровно точно так же

как мне например разделить проект таким образом, чтобы 20 разработчиков могли независимо пилить 20 разных его кусочков

1) бить на микросервисы? (появляется дополнительная работа: поддержка разных версий, сборки и т.п.) 2) просто использовать систему контроля версий?

По такой логике я пихожу к выводу что нужно 2 контейнера: 1) nginx + собранный фронт 2) nginx + phpfpm + собранный бек база не в счет. Но это ж нужно будет тогда сверху накрывать еще одним nginx чтобы раскидывать запросы между фронтом и беком. Получится 3 отдельных nginx. Это разве ок?

да

нет

))

php-fpm без nginx отдельный образ

принцип ларадока?

php-fpm без nginx отдельный образ

А ну да, логично в принципе, экономим один nginx.

Мне почему то всегда казалось что собирать код и какой нибудь fpm в одном контейнере это зло. Видимо я не прав

так критично экономить на легком nginx? может лучше использовать nginx везде, но собирать контейнер на alpine вместо например ubuntu?

так критично экономить на легком nginx? может лучше использовать nginx везде, но собирать контейнер на alpine вместо например ubuntu?

да тут не столько про экономию как таковую.

Хотя если включить зануда mode, то можно сказать что в некоторых ситуациях пачка nginx может вносить существенную задержку. Но не будем об этом сейчас, это оффтоп дикий

Ребзя, помогите с траефиком

не залетают чтото туда хосты

вот композ траефика version: '3' services: traefik: image: traefik:1.5-alpine restart: always container_name: traefik networks: - proxy ports: - "80:80" - "443:443" - "8080:8080" labels: - traefik.frontend.rule=Host:test-traefik.example.com - traefik.port=8080 volumes: - ./traefik:/etc/traefik/ - /var/run/docker.sock:/var/run/docker.sock networks: proxy: external: true

все ок поднимается, вижу веб на 8080

вот поднимаю тестовый нджинкс version: '3' networks: proxy: external: true services: nginx-test: image: nginxdemos/hello restart: always container_name: nginx-test networks: - proxy labels: - traefik.backend=nginx-test - traefik.frontend.rule=Host:tests.example.com - traefik.docker.network=proxy - traefik.port=80

ну и как бы он не заходит

дашборд пуст

А в третьей версии можно установку пакетов добавлять в компоуз?

ERROR: S client not available

народ, а где я продалбываюсь? php: image: php:7.0-fpm restart: always ports: - 9000:9000 command: docker-php-ext-install zip volumes: - ./:/code но в итоге вываливается с exit code 1 и в цикле пытается установить расширение

народ, а где я продалбываюсь? php: image: php:7.0-fpm restart: always ports: - 9000:9000 command: docker-php-ext-install zip volumes: - ./:/code но в итоге вываливается с exit code 1 и в цикле пытается установить расширение

Закомментируй command

без команды все хорошо но как установить расширение?

дашборд пуст

дашборд трэфика?

без команды все хорошо но как установить расширение?

Какое расширение ты пытаешься установить?

дашборд трэфика?

да

пуст в том смысле, что там нет вообще ничего, или нет nginx-бэка и фронта?

Какое расширение ты пытаешься установить?

в конфиге же написано zip

нету nginx бэка и фронта

хм... может конечно это тупость, вроде в докерфайле есть необходимые инструкции, но возможно надо для nginx явно указать порт expose 80?

в конфиге же написано zip

Ок, перефразирую. Расширение к чему ты пыташься установить. У тебя докер не может выполнить в контейнере твой command.

к php

хм... может конечно это тупость, вроде в докерфайле есть необходимые инструкции, но возможно надо для nginx явно указать порт expose 80?

я запускаю этот докеробраз отдельно, он там expose и так

тогда надо логи трэфика

к php

sudo: apt-get update && apt-get install php-zip ?!

тогда надо логи трэфика

root@tests:/home/ubuntu# docker logs traefik root@tests:/home/ubuntu#

ничо нету

дебаг включен в конфиге?

неа

ща включу

sudo: apt-get update && apt-get install php-zip ?!

со стандартными образами docker для php не работал, как понимаю? там явно указано как надо устанавливать расширения

дебаг включен в конфиге?

включил, перезапустил тестовый nginx

в логе только time="2018-02-14T12:23:43Z" level=debug msg="Basic auth success..."

оба хоста вижу в одной сети "Containers": { "838989a60cbeb40a6f880a4c4abe5916f6603657e2cc2bc2bea9e33a866cfdaa": { "Name": "nginx-test", "EndpointID": "22db346a8fd23be488e4ec060f7dd47f061471d304b7ca4ae9ae990073440e0d", "MacAddress": "02:42:ac:12:00:03", "IPv4Address": "172.18.0.3/16", "IPv6Address": "" }, "e59b695b5e4f4e3cd04f31a583f2299768423e4b23e8323162ce0cf417f2f05f": { "Name": "traefik", "EndpointID": "840c694e758ed94800a3011d57658dbef1df14ac615ce7b37ef964c51efd1e4f", "MacAddress": "02:42:ac:12:00:02", "IPv4Address": "172.18.0.2/16", "IPv6Address": ""

со стандартными образами docker для php не работал, как понимаю? там явно указано как надо устанавливать расширения

Не работал, но что мешает проверить мой вариант?)

@flomsk хм, а контейнер с nginx здоров?

Не работал, но что мешает проверить мой вариант?)

опыт ? потому что установка расширений происходит через docker-php-ext-install

Sergey да, ща отдельно запустил, есть подозрение на версию траефик

у меня та же версия трэфика, работает без нареканий

хм

точнее, у меня traefik:alpine, но они вроде идентичны

вот TOML logLevel = "DEBUG" defaultEntryPoints = ["http", "https"] [web] address = ":8080" [web.auth.basic] users = ["admin:ххх"] [entryPoints] [entryPoints.http] address = ":80" [entryPoints.http.redirect] entryPoint = "https" [entryPoints.https] address = ":443" [entryPoints.https.tls] [acme] email = "an@example.org" storage = "acme.json" entryPoint = "https" onHostRule = true onDemand = false