вот отличная идея, спасибо!

пожалуйста)

спасибо)

https://github.com/aeroflotsrc/webapp уже все поржали?

echo "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts chmod 644 ~/.ssh/known_hosts или добавить

вечно забываю

#whois Asgoret SRE на галере) приятно познакомиться?

подскажите, что за ошибка в mariadb? ERROR 1349 (HY000) at line 1240: View's SELECT contains a subquery in the FROM clause Нельзя создавать подзапросы во вьюхе?

пытаюсь перенсти базу с mysql в mariadb

подскажите, что за ошибка в mariadb? ERROR 1349 (HY000) at line 1240: View's SELECT contains a subquery in the FROM clause Нельзя создавать подзапросы во вьюхе?

бред какой то

а просто в консоль если зайти

тот же запрос обработан?

тут еще с какой версии ты переносишь на старых мускулях innodb работает по разному

этот запрос даже через mysql workbench нельзя создать, такая же ошибка

этот запрос даже через mysql workbench нельзя создать, такая же ошибка

дай весь квери

тут еще с какой версии ты переносишь на старых мускулях innodb работает по разному

с 5.7 mysql (винда) на 10.1mariadb debian 9

а на debian 9 можно поставить mysql а не mariadb?

да

а на debian 9 можно поставить mysql а не mariadb?

все, кроме игр)

а на debian 9 можно поставить mysql а не mariadb?

можно. но зачем?

маришку обычно в центосы лепят

можно. но зачем?

чтобы заработало ((

а на debian 9 можно поставить mysql а не mariadb?

хоть mssql

маришку обычно в центосы лепят

деб тоже переехал на нее

а чем mariabd лучше, типа новее и всякие фишки?

а чем mariabd лучше, типа новее и всякие фишки?

что-товроде реализации mysql от несогласных с политикой партии разработчиков. которые пошли своим путем

У меня тоже вопрос по логам. Есть 3 контейнера с php-fpm в которых работает приложение. Между контейнерами через балансировщик распраделяется нагрузка. В каждом контейнере приложение пишет свои лога в файлы. Вопрос: как собирать логи приложения например в ELK? Нужно ли напрвлять логи в stdout\stderr вместо файлов чтобы ловить их как логи контейнера docker logs -f? Подскажите верный путь.

--log-driver gelf например можно

--log-driver gelf например можно

это для логов, которые в контейнер пишет процесс запущенный в нем, верно?

Приветствую. Фабула. Никогда не пользовался Logging as a Service. Есть проект в котором такой сервис будет подходящим вариантом. Разворачивать у себя ELK и копаться в нём неделями, что бы понять, "что-куда и как правильно", не очень хочется (в другой раз, когда придёт время, да и сроки жмут). Вопрос. Посоветуйте сервисы, которые предоставляют данную услугу и если возможно с отзывами. Буду благодарен.

это для логов, которые в контейнер пишет процесс запущенный в нем, верно?

Почитай Ман, он вроде все что в docker logs , отправляет в логстеш

народ мож кто сталкивался. есть teamcity с 3мя агентами в контейнерах на кубере. и есть артифактори тоже в контейнере. Тимсити сбокра не проходит, отваливается с ошибкой что не найден http://artifactory.domain.ru. Хотя сам адрес с машины доступен и локально сборка проходит.

народ мож кто сталкивался. есть teamcity с 3мя агентами в контейнерах на кубере. и есть артифактори тоже в контейнере. Тимсити сбокра не проходит, отваливается с ошибкой что не найден http://artifactory.domain.ru. Хотя сам адрес с машины доступен и локально сборка проходит.

днс-то в контейнере работает ? вам точно по fqdn, а не короткому имени ходить нужно ?

Looks like ingress not configured)

подскажите, как убедиться что порт 3306 открыт на debian?

подскажите, как убедиться что порт 3306 открыт на debian?

netstat -l4n | grep 3306

днс-то в контейнере работает ? вам точно по fqdn, а не короткому имени ходить нужно ?

по короткому имени ходит прокся

netstat -l4n | grep 3306

tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN это означает что доступен извне для любого ip?

по короткому имени ходит прокся

ну может как-то по частям отлаживать ?

tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN это означает что доступен извне для любого ip?

Нет

tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN это означает что доступен извне для любого ip?

ждет на 127.0.0.1:3306

только с локального хоста

ждет на 127.0.0.1:3306

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

в my.cnf

ну может как-то по частям отлаживать ?

хотел начать с контейнера, но там нет команд для тестов.

bind_address 0.0.0.0

хотел начать с контейнера, но там нет команд для тестов.

поставь, что мешает-то ?

bind_address 0.0.0.0

спасибо!

Привет, нужен ваш совет. Читаю свежую книжку Seeking SRE. Там в главе про документацию пишут про плейбуки — не в смысле как в Ansible, а в смысле документа с инструкциями на случай любой ситуации с сервисом. Человек читает этот плейбук и по инструкции решает проблему. Один из критериев качества такого плейбука — надёжность/доступность. Буквально: «Is the playbook reliable (highly available)?» Так вот, как можно понять «highly available» в смысле документации? Что инструкции всегда будут выполнимы? Что просто сам документ не протеряется и будет всем доступен? Если нужно больше контекста, спрашивайте, я побольше кусок выложу.

Когда пойму, выложу конспект-перевод этой главы. )

Привет, нужен ваш совет. Читаю свежую книжку Seeking SRE. Там в главе про документацию пишут про плейбуки — не в смысле как в Ansible, а в смысле документа с инструкциями на случай любой ситуации с сервисом. Человек читает этот плейбук и по инструкции решает проблему. Один из критериев качества такого плейбука — надёжность/доступность. Буквально: «Is the playbook reliable (highly available)?» Так вот, как можно понять «highly available» в смысле документации? Что инструкции всегда будут выполнимы? Что просто сам документ не протеряется и будет всем доступен? Если нужно больше контекста, спрашивайте, я побольше кусок выложу.

Мне кажется, это про то, что она должна быть доступна в случае любого аутейджа.

Т.е. что она не упадёт вместе с сервисом?

поставь, что мешает-то ?

Ну честно пока с контейнерами на вы. Yum не стоит?

Привет, нужен ваш совет. Читаю свежую книжку Seeking SRE. Там в главе про документацию пишут про плейбуки — не в смысле как в Ansible, а в смысле документа с инструкциями на случай любой ситуации с сервисом. Человек читает этот плейбук и по инструкции решает проблему. Один из критериев качества такого плейбука — надёжность/доступность. Буквально: «Is the playbook reliable (highly available)?» Так вот, как можно понять «highly available» в смысле документации? Что инструкции всегда будут выполнимы? Что просто сам документ не протеряется и будет всем доступен? Если нужно больше контекста, спрашивайте, я побольше кусок выложу.

если ваш документ лежит в вики, которая в кубернетесе, а кластер упал - увы, инструкция будет недоступна.

Ну честно пока с контейнерами на вы. Yum не стоит?

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

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

Да проблема пока как коммунициповать с контейнерами. Так бы скинул нужный пакет и установил.

Да проблема пока как коммунициповать с контейнерами. Так бы скинул нужный пакет и установил.

это дико неправильно, но я смирился. Захожу через docker exec делаю apt|apk update && install и разбираюсь в чём причина. Минус подхода - пока контейнеры не на проде работают из-под рута.

ERROR: S client not available

Ну и да, после обновления контейнера - всё установленное конечно пропадёт.

это дико неправильно, но я смирился. Захожу через docker exec делаю apt|apk update && install и разбираюсь в чём причина. Минус подхода - пока контейнеры не на проде работают из-под рута.

А если допустим такая ситуация что нет такой команды apt/apk?

А если допустим такая ситуация что нет такой команды apt/apk?

а куда она делась ? бывают, конечно, образы, которые в которых нет bash/ash тут уж сами выбирайте - размер/удобство.

В данном случае образ тимсити агента. Где нет установщиков

Народ, провокационный вопрос: а ещё у кого возникают сомнения на тему 'докер это какая то хрень в не туда' ?

Раньше возникал, сейчас уже нет

Раньше возникал, сейчас уже нет

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

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

нет, начал находить моменты, где “эх, было бы это в контейнере…”

нет, начал находить моменты, где “эх, было бы это в контейнере…”

особенно эалстик с логстешем на 16 тб

Ахахах

что смеёшься, мне тут вообще заявили, что если ставишь эластик в докер и кубер, то ему не надо больше фс тюнить, размер блока

всем привет! ай нид хелп! прошу помочь с проблемой интеграции TeamCity и BitBucket. disclaimer: гуглил, ответа не нашел. проблема в следующем: настроил для конфигурации сборки build feature "publish build status". В настроках конфига сборки прописал cvs root в котором мониторятся ветки refs/pull-requests/* и триггер настроен как +:* при создании пр, битбакет создает две ветки refs/pull-requests/123/from и refs/pull-requests/123/merge тим сити видит эти вновь созданные ветки и запускает 2 билда. причем в битбакете, в пр начинает отображаться значок с билдом в статусе "in progress", но ссылка ведет на билд, который собирается из ветки from, хотя по смыслу ближе ветка merge, т.к. мне надо проверить факт успешности сборки на уже смерженном исходном коде в целевую ветку, а не на исходной, исходную проверяет другая конфигурация, которая чекает фичебранчи. После окончания обеих сборок в тимсите, в битбакете отображается актуальный статус билда, но только того, который с ветки from. это баг, или есть возможность настроить так, чтобы проверялась ветка merge, а не from?

Ну с другой стороны на старости всегда смогу подзаработать если вдруг не обеспечу себе нормальный retirement plan

что смеёшься, мне тут вообще заявили, что если ставишь эластик в докер и кубер, то ему не надо больше фс тюнить, размер блока

Что такое "фс тюнить"? Я вот только недавно вынесла в докер

что смеёшься, мне тут вообще заявили, что если ставишь эластик в докер и кубер, то ему не надо больше фс тюнить, размер блока

А взаимосвязь, конечно, прям очень прямая)

Что такое "фс тюнить"? Я вот только недавно вынесла в докер

размер блока фс

Что такое "фс тюнить"? Я вот только недавно вынесла в докер

у тебя они хотя бы в пару тб ?

Нет конечно)

В лучшем случае в пару сотен мб

А взаимосвязь, конечно, прям очень прямая)

конечно, любое говно поставь в докер и кубер - оно сразу проблемы перестаёт приносить ? - мечта разрабов

конечно, любое говно поставь в докер и кубер - оно сразу проблемы перестаёт приносить ? - мечта разрабов

Вспомнил боян историю про докеры и микросервисы

Это сколько у вас там логи хранятся вообще, на 16ТБ то

Это сколько у вас там логи хранятся вообще, на 16ТБ то

с годика 1,5, если у тебя cassandra/hadoop, kafka, scaka, java, hdfs hbase

А зачем так долго в хистори, если не секрет?

А зачем так долго в хистори, если не секрет?

потому что требования такие, ещё хорошо хоть не 5 лет как на прошлой работе

А, ну если требования и заказчик платит…)

Привет, нужен ваш совет. Читаю свежую книжку Seeking SRE. Там в главе про документацию пишут про плейбуки — не в смысле как в Ansible, а в смысле документа с инструкциями на случай любой ситуации с сервисом. Человек читает этот плейбук и по инструкции решает проблему. Один из критериев качества такого плейбука — надёжность/доступность. Буквально: «Is the playbook reliable (highly available)?» Так вот, как можно понять «highly available» в смысле документации? Что инструкции всегда будут выполнимы? Что просто сам документ не протеряется и будет всем доступен? Если нужно больше контекста, спрашивайте, я побольше кусок выложу.

действительно будет доступна (технически) а по хорошему - и во втором смысле тоже - выполнима, т.е. проверена/не устарела.