Я ставил через kube-deploy , но этот проект уже не развивается давно, и версия там 1.5.1

всем добра! кто-нибудь может поделиться примером конфигурации nginx+php-fpm+postgres?

если гнижку мне прислали, спасибо, конечно, но там одна сжатая глава по кубам, да и убунту у меня, что, конечно, в целом ничего не меняет, но добавляет особенностей. если есть yml-ки готовые, было бы здорово на них взглянуть) а то из официальных примеров по крупицам все собирать приходится

если гнижку мне прислали, спасибо, конечно, но там одна сжатая глава по кубам, да и убунту у меня, что, конечно, в целом ничего не меняет, но добавляет особенностей. если есть yml-ки готовые, было бы здорово на них взглянуть) а то из официальных примеров по крупицам все собирать приходится

Хоть ты и Жук - но книжка - для всех)

Хоть ты и Жук - но книжка - для всех)

я имел в виду это могло быть ответом на мой вопрос)

я имел в виду это могло быть ответом на мой вопрос)

нет просто где то нашел - решил поделиться

В таком случае, стоило об этом написать:) А то ты и правда бросил таак, будто "На,ищи ответ тут!"

А за книжку спассибо)

А что сложного? Делаешь stafull Postgress и делаешь из него сервис. Потом берёшь контейнер с hub.docker.oi с nginx-php-fpm (их та м с десяток, выбираешь который тебе больше нравится)

если гнижку мне прислали, спасибо, конечно, но там одна сжатая глава по кубам, да и убунту у меня, что, конечно, в целом ничего не меняет, но добавляет особенностей. если есть yml-ки готовые, было бы здорово на них взглянуть) а то из официальных примеров по крупицам все собирать приходится

^^

начни с kubectl run <> —image=nginx-php-fpm

https://kubernetes.io/docs/tutorials/stateful-application/run-stateful-application/

А что сложного? Делаешь stafull Postgress и делаешь из него сервис. Потом берёшь контейнер с hub.docker.oi с nginx-php-fpm (их та м с десяток, выбираешь который тебе больше нравится)

разве не нужно nginx и fpm делать раздельными сервисами? по сути Вы предлагаете собрать контейнер all-in-one для конкретного приложения, что по идее идет в разрез с принципами docker

тут как работать со statfull (Тут правда Mysql Но разница не велика)

Хочешь сделай отдельно)

Ну базу то я тебе не предлагаю туда поставить

Хочешь сделай отдельно)

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

нет сервис будет одн nginx и один fpm

за каждым сервисом будет по n подов

и соответвенно nginx будет тянуть данный от fpm

от сервиса fpm

т.е. будет один большущий конфиг для nginx?

по сути в конфиге nignx у тебя будет

fpm.svc:9000;

просто еще разные конфиги для dev-stage-prod..

вместо локалхоста

видиме я не доконца понимаю ахитектуру твоего вопроса

у тебя 5 разных fpm с разным окружением?

и в чём разница между 5 nginx?

разве не нужно nginx и fpm делать раздельными сервисами? по сути Вы предлагаете собрать контейнер all-in-one для конкретного приложения, что по идее идет в разрез с принципами docker

по-хорошему надо, но вопрос в том, сможете ли вы запихнуть статику приложения в один контейнер, а код в другой. большинство именно из-за этого не делят.

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

сам я фанат разделения, если что

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

Дело говорит)

+1

в идеале у вас ui и бэкенд - это два разных приложения, причем ui - это исключительно статика

в идеале у вас ui и бэкенд - это два разных приложения, причем ui - это исключительно статика

ну так и есть) ui - это extjs, прикомпиленый. и nginx по умоланию всё редиректит на index.html, кроме запросов типа /api/, которые, соответственно, редиректятся на fpm

так что в fpm статики нет вообще

тогда поделить должно быть легко

тогда поделить должно быть легко

да, но.. как я уже писал, начинается проблема дублирования сервисов. ну не совсем дублирования, пересекаться они, конечно, не будут, но управлять ими становится сложно, особенно, когда долго не лезешь в рабочий процесс, а потом надо что-то переконфигурировать)

по разным неймспейсам просто разбить

и, в идеале, добавить генерацию файлов для куба прямо в приложение

по разным неймспейсам просто разбить

в офф доках советуют неймспейсам делить рабочие окружения, про разделение приложений не слова)

я пока увидел, что вы хотите разбить prod/dev/test

да

и приложения)

namespace: {{application_name}}-production

хотя сами по себе приложения должны оформляться одним подом

если у вас там только не совсем микросервисно

если у вас там только не совсем микросервисно

в том-то и дело, что хочется совсем. мы все сервисы переносим на куб, а я, к сожалению, в этом профан оказался) когда только пришел, переписал всё на docker-compose, и вручную (Makefile) поднимал-тормозил сервисы. и наивно полагал, что куб - похожая ерунда, и проблем не возникнет))

вот и ищу best practice

да в общем-то похожая, просто yml побольше

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

да в общем-то похожая, просто yml побольше

.. и конфиги мапятся, а не монтируются, и ингрессии, и CI для сборки своих контейнеров, хоть я пока и далек от этих шагов)..

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

инфы куча, она периодически дублируется и взаимоисключается))

пока только понравился ман в coreos

но у меня убунту(

кто-нибудь, кстати, сталкивался с juju и прокидыванием портов?

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

1. Конфиги можно мапить через config map, можно держать и в контейнере. Best practic такая. Держать дефолтовый в контейнере. и потом мапить нужный

по сути config map это просто фаил конфигурации который монтируется в нужною точнку контенера через -v ключ докера

[root@222720-10009 ~]# kubectl get cm prometheus -o yaml apiVersion: v1 data: prometheus.yml: "# A scrape configuration for running Prometheus on a Kubernetes cluster.\n

ERROR: S client not available

а вот из deployment

volumes: - configMap: defaultMode: 420 name: prometheus name: config-volume volumeMounts: - mountPath: /etc/prometheus name: config-volume

По сути в cm хрнаится фаил конфигурации который монтируется в /etc/prometheus

создать cm можно простой командой kubectl create cm <name> —from-file=<file>

Ingress это способ вывода приложения в мир через Ingress Controller (Обычно GCE или Nginx, Хотя сейчас вроде как HAproxy пилят) То есть твоё приложения помещается за прокси сервером. (при том сам прокси берёт из сервиса только endpoint то есть адреса подов)

по сути приложение работающие в docker-compose не так сложно перевести в кубер

по сути приложение работающие в docker-compose не так сложно перевести в кубер

тем более есть kompose

спасибо за конфиги) собственно, так и сделано, только на проде еще одна прослойка в виде juju. читал по ней маны, но думаю снесу нафиг и поставлю с нуля куб по офф докам

спасибо за конфиги) собственно, так и сделано, только на проде еще одна прослойка в виде juju. читал по ней маны, но думаю снесу нафиг и поставлю с нуля куб по офф докам

еще то занятие...впереди выходные =)))

еще то занятие...впереди выходные =)))

норм, как раз навык прокачать)

тем более есть kompose

Какая интересная штука)

тем более есть kompose

а я поначалу подумал, что вы опечатались)

спасибо за наводку

нет, не опечатка)

есть ли смысл ставить куб на kvm/lxc? или если пока нет необходимости, лучше ставить bare metal и потом замасштабировать?

ну в lxc точно смысла особого нет) контейнер в контейнере. Тем более что и докер и lxc работаю на cgroups

ну а так типовой стек какой? у меня будут минимум 2 сервера, причём каждый со своим мастером

open stack или так ставить, bare metal?

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

разве так не гибче выходит? взять те же маны по карго, там опенстэк

кто как разворачивает кубер?

кто как разворачивает кубер?

использую кукбук от Злых Марсиан. У меня только с ним получилось заставить работать мультимастер

для тестов отлично подходит kubeadm

кто как разворачивает кубер?

1. Есть такая штука - https://coreos.com/tectonic/ 2. У нас свой инсталлер на Ansible, который разворачивает нужные настройки безопасности, сверху Kubernetes, сбоку Docker Registry, Concourse CI, Grafana, Telegraf, InfluxDB. Следующее в плане добавить: 1. Git Workflow (dev/stage/production/feature branches) 2. Project Profiles

1. Есть такая штука - https://coreos.com/tectonic/ 2. У нас свой инсталлер на Ansible, который разворачивает нужные настройки безопасности, сверху Kubernetes, сбоку Docker Registry, Concourse CI, Grafana, Telegraf, InfluxDB. Следующее в плане добавить: 1. Git Workflow (dev/stage/production/feature branches) 2. Project Profiles

то есть вы скопировали kargo?

В каком то смысле

В каком то смысле

был глобальный смысл или because we can? Если не секрет, конечно

то есть вы скопировали kargo?

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

был глобальный смысл или because we can? Если не секрет, конечно

Во первых, мы были первые :) В том смысле, что мы это сделали давно (мы около года назад начали натягивать кубик в прод), во вторых разные специфичные кейсы. Сейчас мы просто задаём список из IP, логины и пароли - кластер и окружение сбоку настраиваемся на указанных машинах. Короче, one click ?

кто как разворачивает кубер?

kube-aws + тоненькая обвязка на bash для работы с гит ветками

kube-aws + тоненькая обвязка на bash для работы с гит ветками

А что делает с ветками?