Про идею хранить то, что предполагается как прямой io в сети.
Никто из разработчиков никогда про это не подумает. И однажды это больно укусит строителя такой системы за жопу.
Учитывая последние новости про EKS, поход докера в поддержку кубера и разворачивание кубера одной кнопкой в docker for mac (beta) — приходится признать, что k8s становится отраслевым стандартом и глупо это игнорировать.
Но я бы не стал использовать весь диапазон его фич.
> Но когда речь заходит о кластере, отказоустойчивсти, CI, rolling-update или statefull-приложениях я бы всерьез рассмотрел Kubernetes на эту роль.
Это очень идеалистичный взгляд на мир. На самом деле всё вот это невозможно сделать ТОЛЬКО на уровне ops и оркестрации, не учитывая особенности приложения.
А если всё равно часть надо делать в приложении с учётом опыта разработчиков — почему не сделать это всё там? Тот вариант который я описывал в докладе не пытается решать проблему мирового голода и ответить на главный вопрос жизни, вселенной и всего остального.
Именно. А ещё swarm можно развернуть локально, а кубер — почти нет. :)
Это была тема довольно долгой и горячей дискуссии на РИТ сразу после моего выступления.
Кубер нравится админам своей фичастостью. Для разработчика он добавляет ещё один, довольно широкий, пласт абстракции и новую предметную область. И это проблема.
Но вообще, если посмотреть на то что мы в итоге получили — это ведь даже не swarm (мы от него фактически только scheduling) используем. Это ОЧЕНЬ простая система, которая ОЧЕНЬ завязана на внутренние соглашения в команде и знание про окружающий ландшафт. Поэтому она довольно бодро работает.
> поскольку за полчаса не понял как сделать мастер-мастер репликацию
Нужно читать сайт и блок перконы (http://percona.com), ключевые термины — pxc (синхронная репликация в mysql почти из коробки) и proxysql (который с недавних пор они пакуют в pxc).
Я использую Time Machine для бэкапа домашних ноутов на Mac Mini (на котором OSX Server стоит).
В целом — все более чем устраивает (оно действительно работает), хотя периодически встречаются дурацкие баги из серии «не буду бэкапиться, бэкап уже кто-то пользует», которые решаются только удалением бэкапа и полным бэкапом заново. Но все эти мелочи компенсируются возможностью «тупо восстановиться» родным для мака способом.
Для резервного бэкапа я использую Backblaze, который за пять баксов в месяц тихонечко бэкапит все что есть на машине и на usb-дисках, которые периодически подключаются к ноуту, в облако. Скорость аплоада не очень высокая, конечно, но если дождаться первого бэкапа, то day-to-day бэкап в стиле дропбокса работает прекрасно. Возможность выдернуть из бэкапа отдельные файлы через веб или мобильное приложение — крайне удобная фича, которой я пользовался не один десяток раз.
Никто из разработчиков никогда про это не подумает. И однажды это больно укусит строителя такой системы за жопу.
Но я бы не стал использовать весь диапазон его фич.
Во-первых, это одна из причин, по которой мы не стали использовать networking докера.
Во-вторых, сейчас всё лучше.
Это очень идеалистичный взгляд на мир. На самом деле всё вот это невозможно сделать ТОЛЬКО на уровне ops и оркестрации, не учитывая особенности приложения.
А если всё равно часть надо делать в приложении с учётом опыта разработчиков — почему не сделать это всё там? Тот вариант который я описывал в докладе не пытается решать проблему мирового голода и ответить на главный вопрос жизни, вселенной и всего остального.
нуууу…
> Поработав с kubernetes, он тоже становиться простым и понятным, если смотреть со стороны разработчика
В чём угодно можно разобраться — вопрос только в целесообразности введения ещё одного уровня абстракции.
Разное окружение при разработке и на проде (или тестовой среде) — это плохо.
А ты админ, да? :)
Кубер действительно любят админы. :)
Ну проблема в том, что «заставлять» — против моей личной идеологии, а значит надо дать инструменты. :)
1) это медленно
2) все равно нужно решать вопросы с надежностью
:)
Это была тема довольно долгой и горячей дискуссии на РИТ сразу после моего выступления.
Кубер нравится админам своей фичастостью. Для разработчика он добавляет ещё один, довольно широкий, пласт абстракции и новую предметную область. И это проблема.
Но вообще, если посмотреть на то что мы в итоге получили — это ведь даже не swarm (мы от него фактически только scheduling) используем. Это ОЧЕНЬ простая система, которая ОЧЕНЬ завязана на внутренние соглашения в команде и знание про окружающий ландшафт. Поэтому она довольно бодро работает.
Во-первых, это медленно. Во-вторых, на той стороне nfs это тоже надо реплицировать, бэкапить, вот это всё.
Нужно читать сайт и блок перконы (http://percona.com), ключевые термины — pxc (синхронная репликация в mysql почти из коробки) и proxysql (который с недавних пор они пакуют в pxc).
https://en.wikipedia.org/wiki/Soft_skills
:)
В целом — все более чем устраивает (оно действительно работает), хотя периодически встречаются дурацкие баги из серии «не буду бэкапиться, бэкап уже кто-то пользует», которые решаются только удалением бэкапа и полным бэкапом заново. Но все эти мелочи компенсируются возможностью «тупо восстановиться» родным для мака способом.
Для резервного бэкапа я использую Backblaze, который за пять баксов в месяц тихонечко бэкапит все что есть на машине и на usb-дисках, которые периодически подключаются к ноуту, в облако. Скорость аплоада не очень высокая, конечно, но если дождаться первого бэкапа, то day-to-day бэкап в стиле дропбокса работает прекрасно. Возможность выдернуть из бэкапа отдельные файлы через веб или мобильное приложение — крайне удобная фича, которой я пользовался не один десяток раз.
Jira очень generic система. Многих вещей там просто невозможно добиться по-человечески. Multiple assignments, например.