Maksim
https://kubernetes.io/docs/tutorials/stateful-application/run-stateful-application/
Maksim
тут как работать со statfull (Тут правда Mysql Но разница не велика)
Maksim
Хочешь сделай отдельно)
Maksim
Ну базу то я тебе не предлагаю туда поставить
𝕍ℤ
Хочешь сделай отдельно)
и тут начинаются вопросы) что, например, делать, когда я задеплою все приложения на куб? стеки у них схожие, и выйдет 5 сервисов nginx, 5 сервисов fpm и т.д.
Maksim
нет сервис будет одн nginx и один fpm
Maksim
за каждым сервисом будет по n подов
Maksim
и соответвенно nginx будет тянуть данный от fpm
Maksim
от сервиса fpm
𝕍ℤ
т.е. будет один большущий конфиг для nginx?
Maksim
по сути в конфиге nignx у тебя будет
Maksim
fpm.svc:9000;
𝕍ℤ
просто еще разные конфиги для dev-stage-prod..
Maksim
вместо локалхоста
Maksim
видиме я не доконца понимаю ахитектуру твоего вопроса
Maksim
у тебя 5 разных fpm с разным окружением?
Maksim
и в чём разница между 5 nginx?
Etki
Etki
польза от этого понятна, но там вылезает столько геморроя, что по затратам проще брякнуть один контейнер.
Etki
сам я фанат разделения, если что
Maksim
yolkov
+1
Etki
в идеале у вас ui и бэкенд - это два разных приложения, причем ui - это исключительно статика
𝕍ℤ
так что в fpm статики нет вообще
Etki
тогда поделить должно быть легко
𝕍ℤ
тогда поделить должно быть легко
да, но.. как я уже писал, начинается проблема дублирования сервисов. ну не совсем дублирования, пересекаться они, конечно, не будут, но управлять ими становится сложно, особенно, когда долго не лезешь в рабочий процесс, а потом надо что-то переконфигурировать)
Etki
по разным неймспейсам просто разбить
Etki
и, в идеале, добавить генерацию файлов для куба прямо в приложение
Etki
я пока увидел, что вы хотите разбить prod/dev/test
𝕍ℤ
да
𝕍ℤ
и приложения)
Etki
namespace: {{application_name}}-production
Etki
хотя сами по себе приложения должны оформляться одним подом
Etki
если у вас там только не совсем микросервисно
𝕍ℤ
если у вас там только не совсем микросервисно
в том-то и дело, что хочется совсем. мы все сервисы переносим на куб, а я, к сожалению, в этом профан оказался) когда только пришел, переписал всё на docker-compose, и вручную (Makefile) поднимал-тормозил сервисы. и наивно полагал, что куб - похожая ерунда, и проблем не возникнет))
𝕍ℤ
вот и ищу best practice
Etki
да в общем-то похожая, просто yml побольше
Etki
я боюсь, я пока так и не понял, откуда вылезает боль при администрировании
𝕍ℤ
и самое главное дикие боли по поводу непрозрачных доков
𝕍ℤ
инфы куча, она периодически дублируется и взаимоисключается))
𝕍ℤ
пока только понравился ман в coreos
𝕍ℤ
но у меня убунту(
𝕍ℤ
кто-нибудь, кстати, сталкивался с juju и прокидыванием портов?
Maksim
Ну читать доку по куберу это отдельный навык) Приобретается со временем)
Maksim
1. Конфиги можно мапить через config map, можно держать и в контейнере. Best practic такая. Держать дефолтовый в контейнере. и потом мапить нужный
Maksim
по сути config map это просто фаил конфигурации который монтируется в нужною точнку контенера через -v ключ докера
Maksim
[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
Maksim
а вот из deployment
Maksim
volumes:
- configMap:
defaultMode: 420
name: prometheus
name: config-volume
volumeMounts:
- mountPath: /etc/prometheus
name: config-volume
Maksim
По сути в cm хрнаится фаил конфигурации который монтируется в /etc/prometheus
Maksim
создать cm можно простой командой kubectl create cm <name> —from-file=<file>
Maksim
Ingress это способ вывода приложения в мир через Ingress Controller (Обычно GCE или Nginx, Хотя сейчас вроде как HAproxy пилят) То есть твоё приложения помещается за прокси сервером. (при том сам прокси берёт из сервиса только endpoint то есть адреса подов)
Maksim
по сути приложение работающие в docker-compose не так сложно перевести в кубер
Anonymous
𝕍ℤ
спасибо за конфиги) собственно, так и сделано, только на проде еще одна прослойка в виде juju. читал по ней маны, но думаю снесу нафиг и поставлю с нуля куб по офф докам
Knyage
𝕍ℤ
𝕍ℤ
спасибо за наводку
Anonymous
нет, не опечатка)
𝕍ℤ
есть ли смысл ставить куб на kvm/lxc? или если пока нет необходимости, лучше ставить bare metal и потом замасштабировать?
Maksim
ну в lxc точно смысла особого нет) контейнер в контейнере. Тем более что и докер и lxc работаю на cgroups
𝕍ℤ
ну а так типовой стек какой? у меня будут минимум 2 сервера, причём каждый со своим мастером
𝕍ℤ
open stack или так ставить, bare metal?
Etki
если вам не нужен опенстек как таковой, то зачем его ставить?
𝕍ℤ
разве так не гибче выходит? взять те же маны по карго, там опенстэк
Oleg
кто как разворачивает кубер?
Logan
для тестов отлично подходит kubeadm
Denis
кто как разворачивает кубер?
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
Logan
Denis
В каком то смысле
Logan
В каком то смысле
был глобальный смысл или because we can? Если не секрет, конечно
Denis
был глобальный смысл или because we can? Если не секрет, конечно
Во первых, мы были первые :) В том смысле, что мы это сделали давно (мы около года назад начали натягивать кубик в прод), во вторых разные специфичные кейсы.
Сейчас мы просто задаём список из IP, логины и пароли - кластер и окружение сбоку настраиваемся на указанных машинах. Короче, one click 👍