KK
Выкачивать? Нет я зайду в "веб-админку" конкретного стенда 😊
Size: a a a
2020 April 16
БС
Ой да, прикрутить примитивный поиск к админке, у которой есть все схемы - это же просто.
вот когда прикрутишь.. тогда и поговорим. Если бы это было просто, это было бы везде.. В старых вижуал студиях этого не было и это бесило. Относительно недавно это добавили..
БС
Выкачивать? Нет я зайду в "веб-админку" конкретного стенда 😊
у тебя стенд состоит из десятка серверов..
KK
Ну я как бы тоже.. Только у нас конфиги делаются из шаблона который лежит в гите и скрипты которые выдерают инфу из всяких терраформов, чтобы прокинуть нужное значение в конфиг, тоже лежат в gitе.
Мне почти никогда не надо лезть на прод чтобы посмотреть на конфиг. Я его вижу в исходниках
Мне почти никогда не надо лезть на прод чтобы посмотреть на конфиг. Я его вижу в исходниках
У нас нет всего этого. Это "сложнааа", это надо настраивать. И настраивать для каждой инсталяции. А если будут изменения в схеме - менять на всех инсталяциях. И конечно же где-то что-то сделают не так и деплой на стрендах будет отличаться. Потому что гладиолус и делал всё это не я, а админ, который не знает каких-то особенностей.
БС
и при деплое случайное значение оказалось на одном из серваков
A
Я решаю свою реальную боль - конфиги на стендах меняю в основном Я, или я подсказываю что надо поменять. Я не могу быстро посмотреть что-же там настроено на сервере и всё ли правильно. Потому что для этого надо лезть на сервер, искать файл, смотреть на него в унылом "чёрно-белом" виде. И при этом не видно какие именно настройки отличаются от дефолта.
зачем на сервер? Смотреть надо в git.
A
Хотя бы по репозиторию с конфигами на деплой.
KK
и при деплое случайное значение оказалось на одном из серваков
Поэтому я выше и писал, что конфиги в файлах на больших системах - это зло. Конфиг должен быть в одном месте. Проще всего в базе данных, которую юзеает проект. Но можно и специализированную.
А без базы так и будет всегда вероятность что конфиги на серверах разъедутся.
А без базы так и будет всегда вероятность что конфиги на серверах разъедутся.
KK
В файле достаточно хранить настройки конекта к базе и всё.
A
Поэтому я выше и писал, что конфиги в файлах на больших системах - это зло. Конфиг должен быть в одном месте. Проще всего в базе данных, которую юзеает проект. Но можно и специализированную.
А без базы так и будет всегда вероятность что конфиги на серверах разъедутся.
А без базы так и будет всегда вероятность что конфиги на серверах разъедутся.
Я у вас настолько больших систем не видел. Если конфиги раскатываются автоматизированно, то не разъедутся.
БС
Для того чтобы гарантировано не разъехалось, можно замонтировать диск с одним конфигом на все сервера
KK
Я у вас настолько больших систем не видел. Если конфиги раскатываются автоматизированно, то не разъедутся.
Знаешь у нас за 8 лет они так и не стали нормально раскатываться автоматически. 😊
Самое крутое что есть - на ноде с salt-ом есть bash скрипт, который позволяет обновить на всех виртуалках конфиг бекенда, копия которого лежит там же (и недавно появилась фича, что бы перезапустить бекенды). Но кроме бекенда есть ещё 2-3 микросервиса. И для них нет такого скрипта.
А на 1 или двух стендах даже такого скрипта нет.
Самое крутое что есть - на ноде с salt-ом есть bash скрипт, который позволяет обновить на всех виртуалках конфиг бекенда, копия которого лежит там же (и недавно появилась фича, что бы перезапустить бекенды). Но кроме бекенда есть ещё 2-3 микросервиса. И для них нет такого скрипта.
А на 1 или двух стендах даже такого скрипта нет.
БС
Я у вас настолько больших систем не видел. Если конфиги раскатываются автоматизированно, то не разъедутся.
пару раз видел проблемы. Один раз конфиг просто не доехал, но деплой не упал.
Второй раз из за баги в коде шаблон на сервак при стечении всяких обстоятельств глючил.
Второй раз из за баги в коде шаблон на сервак при стечении всяких обстоятельств глючил.
A
Для того чтобы гарантировано не разъехалось, можно замонтировать диск с одним конфигом на все сервера
и получить единую точку отказа
БС
нет, конфиг же читается во время старта.. Если диск будет не доступен какое то время во время работы, ничего страшного не произойдет. Но да, любое решение должно быть анализироваться.
A
Знаешь у нас за 8 лет они так и не стали нормально раскатываться автоматически. 😊
Самое крутое что есть - на ноде с salt-ом есть bash скрипт, который позволяет обновить на всех виртуалках конфиг бекенда, копия которого лежит там же (и недавно появилась фича, что бы перезапустить бекенды). Но кроме бекенда есть ещё 2-3 микросервиса. И для них нет такого скрипта.
А на 1 или двух стендах даже такого скрипта нет.
Самое крутое что есть - на ноде с salt-ом есть bash скрипт, который позволяет обновить на всех виртуалках конфиг бекенда, копия которого лежит там же (и недавно появилась фича, что бы перезапустить бекенды). Но кроме бекенда есть ещё 2-3 микросервиса. И для них нет такого скрипта.
А на 1 или двух стендах даже такого скрипта нет.
А на соседнем проекте я сделал так что все катится одним плейбуком ansible из гита через jenkins.
KK
А на соседнем проекте я сделал так что все катится одним плейбуком ansible из гита через jenkins.
Ну хоть что-то, но всё равно "сложна":
- пойти в гит. Ещё и вспомнить где он там, найти его в битбакете (у меня это почему-то вызывает сложности)
- поправить конфиг в гите
- пойти в Jenkins, найти там кнопку (это проблема, если там 100500 кнопок)
- подождать пока всё применится и перезапустится
- понять что допустил косяк в конфиге и повторить всё с начала 😊
- пойти в гит. Ещё и вспомнить где он там, найти его в битбакете (у меня это почему-то вызывает сложности)
- поправить конфиг в гите
- пойти в Jenkins, найти там кнопку (это проблема, если там 100500 кнопок)
- подождать пока всё применится и перезапустится
- понять что допустил косяк в конфиге и повторить всё с начала 😊
KK
А если надо поменять "секретную" настройку, то пойти вместо гита в ещё какое-то другое место, где хранятся секреты.
БС
Ну хоть что-то, но всё равно "сложна":
- пойти в гит. Ещё и вспомнить где он там, найти его в битбакете (у меня это почему-то вызывает сложности)
- поправить конфиг в гите
- пойти в Jenkins, найти там кнопку (это проблема, если там 100500 кнопок)
- подождать пока всё применится и перезапустится
- понять что допустил косяк в конфиге и повторить всё с начала 😊
- пойти в гит. Ещё и вспомнить где он там, найти его в битбакете (у меня это почему-то вызывает сложности)
- поправить конфиг в гите
- пойти в Jenkins, найти там кнопку (это проблема, если там 100500 кнопок)
- подождать пока всё применится и перезапустится
- понять что допустил косяк в конфиге и повторить всё с начала 😊
ну конечно, гораздо лучше пойти в админку поменять параметр, не проверить что именно это параметр будет нормально работать на этом серваке и уйти в отпуск.
Потом через неделю всё упадет, и все будут сначала разбираться, что ничего не трогали, а оно упало, потом обнаружат что в базе лежит не то значения, но кто его испортил никто никогда не узнает..
Потом через неделю всё упадет, и все будут сначала разбираться, что ничего не трогали, а оно упало, потом обнаружат что в базе лежит не то значения, но кто его испортил никто никогда не узнает..
KK
ну конечно, гораздо лучше пойти в админку поменять параметр, не проверить что именно это параметр будет нормально работать на этом серваке и уйти в отпуск.
Потом через неделю всё упадет, и все будут сначала разбираться, что ничего не трогали, а оно упало, потом обнаружат что в базе лежит не то значения, но кто его испортил никто никогда не узнает..
Потом через неделю всё упадет, и все будут сначала разбираться, что ничего не трогали, а оно упало, потом обнаружат что в базе лежит не то значения, но кто его испортил никто никогда не узнает..
Зависит от того как хорошо напишешь валидатор в схеме. Если спустя рукава, и не огрничишь значение допустимыми вариантами, не добавишь проверку что параметры конекта к S3 валидные и работают - тогда так и будет.
А если всё это предусмотреть, точно так же как это делается в любом API методе, которые дёргают юзеры - тогда вероятность факапа сильно ниже.
А если всё это предусмотреть, точно так же как это делается в любом API методе, которые дёргают юзеры - тогда вероятность факапа сильно ниже.