Я согласен с коллегой, что ансибл местами непоследователен. В моем идеальном мире тоже все программы без багов и розовых коней по углам. К сожалению, реальный мир не такой. И приходится приспосабливаться к ограничениям инструмента и к тому, что в каждой следующей версии ломают поведение предыдущей. И это не проблема ансибла как такового. А, в целом, всей индустрии.
все тесты проходили на "ура", просто была "небольшая путаница в ip".
Во-первых, нужен канареечный релиз, чтобы такое отлаживать. Да, отладка на продакшене. А что делать!?
Во-вторых, это может приводить к факапам, как, например, у яндекса, с мисконфигурацией сетевых устройств. ЛЕГКО.
Хуже того — при наличии доступа в интернет с клиентского устройства, даже при наличии ОН ПРЕМИС установки гитлаба, эти скрипты трекинга могли посылать данные на внешние, 3-и сервера. Т.е. закрытый контур еще не гарантия отсутствия утечки данных, как тут некоторые пытались заявить.
Еще одна причина, почему я не хочу писать на плюсах… А прикиньте — вот эти нюансы будут исчезать и появляться в разных версиях стандарта, компиляторы будут их с опозданием реализовывать… а потом программисты будут удивляться — почему это программа сломалась.
Очень сложная, очень ответственная работа!
Могу пожелать только, чтобы сделали процесс максимально автоматизированным, надежным и простым. И он не вызывал излишней головной боли. А то тестирование по две недели… жестко. Это не скриптики на питоне кодить.
Удачи!
Потому что, очевидно, нет понятия миграции контейнеров. Они же иммутабельные и созданы, чтобы умирать. Это раз.
Два — это подразумевает кластерное решение вроде кубернетеса. А там свой процесс. И более того — свои особенности. И докИр там не нужен.
Я уж не говорю о том, что есть вероятность, что не все контейнеры управляются оркнстратором типа кубернетеса. Например, ранчер любит системные компоненты вроде кьюьлета запускать в докере вне куба. А не в системди сервисе.
Три — мне показалось, или это так и есть, но автор рассматривал безопасность именно standalone docker нод
Очень интересно.
Сколько примерно по времени занимает такое тестирование?
Получается, его нужно накатывать на каждое изменение (=ежемесячно или чаще)?
Что делать, если необходимо протестировать какие-то специфические вещи — межпериодные выплаты, вроде больничных, отпусков, возврата 2ндфл и пр.?
Автоматизация присутствует? Очень интересно было бы почитать
контейнер с за'fail'енной пробой все равно будет работать, если не применять костыли… вроде https://hub.docker.com/r/willfarrell/autoheal/
А с ним я имел много приятных минут, когда он ломал деплой (ес-но — контейнер убивался, он его восстанавливал старой версии и все разваливалось).
А если через VPN? Если нужно — можно ужасы типа VDI без возможности скопипастить информацию + шпион на ноутбук сотрудника, что он гарантированно ничего не утащит.
так как это нарушит GDPR
Ну, и насколько я помню — там речь шла про обработку и хранение данных, так что кейс с ssh надуман. И еще — ведь можно же реплику держать вне ЕС? Можно.
Технические решения с разделением доступа нужны не только для того, чтобы обеспечить возможность работы условного Васи из Мухосранска. А скорее — для того, чтобы проходить комплайенс и показывать клиентам "какие мы крутые ребята — у нас все по процессам и безопасно". Заодно можно привлечь гос и окологос клиентов. То, что при это можно нанять Васю и он не сможет нанести вреда — только плюс.
Microsoft не бил себя ТОГДА пяткой в грудь, что они оплот опенсурса, демократии, отсутствия дискриминации… Возможно просто наши ожидания от ГитЛаба завышены. Не более.
Первое. Вы правда думаете, что какая-нибудь гос или окологос структура будет счастлива пользоваться облачным гитлабом (который gitlab.com)? Где ее данные и данные других клиентов перемешаны непонятно каким образом?
К этому же — если они все-таки берут он-премис инстанс, то как влияет местоположение разработчика на возможность заложить закладку в ПО? При наличии процесса код ревью (ответ — минимально).
Если у них он-премис — они (клиенты) могут вообще ПОТРЕБОВАТЬ физического нахождения сотрудника техпода на площадке. Или нет? Или это только в головах российских компаний, у которых "везде враги", а американцы сплошь в облаке сидят?
Второе — «second class of citizens» — это полный булшит. Всегда есть сотрудники с разным уровнем доступа. Как если сравнивать сотрудников на разных уровнях должностной лестницы (VP против сотрудника техпода), так и на примерно одинаковых уровных (у одного есть форма допуска к секретам, у другого — нет).
А чего тогда американским клиентам не потребовать того, чтобы их поддержкой (извините, накидываю) занимались белые гетеросексуальные американские граждане? Или поддержкой американцев могут заниматься только жители стран второго мира (ибо дешево)?
На самом деле проблема чисто в головах и в плоскости процессов. Гитлабу НИКТО не мешает устанавливать выделенные инстансы для американцев с паранойей (напр., госструктурам), которые будут обслуживать отдельные команды внутри компании. И об этом в комментах, кстати, писали.
К тому же, лимит сотрудников на России и Китай по 5 человек из которых практически все разработчики.
Это тоже выглядит как глупость. Вот найдут они шестого суперталантливого разработчика — и что? Отказывать ему потому что он в России/Китае? А прикрываются мультикультурализмом и прочими общими местами. Короче, выглядит так, что ГитЛаб занимается зарабатыванием денег и все. Остальное по барабану.
Я бы так остро не реагировал, но это второй их серьезный прокол — первым был трекинг. Опять же — трекинг пользователей — это про зарабатывание $$$$, а не про… "делать хороший продукт"
Безусловно, можно сделать для особо привередливых клиентов отдельный кластер и не пускать туда никого, но обновлять, например, как?
Так же — как и обычно. Это не является какой-то гипер-сложной или непонятной, нерешаемой технической задачей. У них же есть внутри Gitlab-EE своя репликация (GitLab Geo), поэтому тем более не понимаю Ваших… недоумений.
Они имеют право делать так, но это… не по-человечески. Если так — им нужно сворачивать свой CE, в который вложились люди по всему миру, независимо от религии, места проживания и пр. атрибутов, и становиться полностью закрытойкоммерческой организацией по типу Slack/Atlassian. Тогда бы вопросов не было. Но ожидания такие, что ГитЛаб — оплот опенсурса и соответственно должен вести себя так же.
Облако сложно. Во-первых, где гарантия, что спустя год, два, пять — облако не станет тыквой? Во-вторых — где гарантия, что Ваш условный архив домашнего видео облако не сольет куда-либо? В частности, если там может быть чувствительная информация. В принципе, это все решаемо — рассовыванием зашифрованных данных по нескольким облакам, но локальное хранилище проще. Но ОБЫЧНОМУ потребителю, который только и умеет, что в гуглопочту и вконтактик — облако проще.
Я согласен с коллегой, что ансибл местами непоследователен. В моем идеальном мире тоже все программы без багов и розовых коней по углам. К сожалению, реальный мир не такой. И приходится приспосабливаться к ограничениям инструмента и к тому, что в каждой следующей версии ломают поведение предыдущей. И это не проблема ансибла как такового. А, в целом, всей индустрии.
Во-первых, нужен канареечный релиз, чтобы такое отлаживать. Да, отладка на продакшене. А что делать!?
Во-вторых, это может приводить к факапам, как, например, у яндекса, с мисконфигурацией сетевых устройств. ЛЕГКО.
Хуже того — при наличии доступа в интернет с клиентского устройства, даже при наличии ОН ПРЕМИС установки гитлаба, эти скрипты трекинга могли посылать данные на внешние, 3-и сервера. Т.е. закрытый контур еще не гарантия отсутствия утечки данных, как тут некоторые пытались заявить.
Еще одна причина, почему я не хочу писать на плюсах… А прикиньте — вот эти нюансы будут исчезать и появляться в разных версиях стандарта, компиляторы будут их с опозданием реализовывать… а потом программисты будут удивляться — почему это программа сломалась.
Очень сложная, очень ответственная работа!
Могу пожелать только, чтобы сделали процесс максимально автоматизированным, надежным и простым. И он не вызывал излишней головной боли. А то тестирование по две недели… жестко. Это не скриптики на питоне кодить.
Удачи!
Потому что, очевидно, нет понятия миграции контейнеров. Они же иммутабельные и созданы, чтобы умирать. Это раз.
Два — это подразумевает кластерное решение вроде кубернетеса. А там свой процесс. И более того — свои особенности. И докИр там не нужен.
Я уж не говорю о том, что есть вероятность, что не все контейнеры управляются оркнстратором типа кубернетеса. Например, ранчер любит системные компоненты вроде кьюьлета запускать в докере вне куба. А не в системди сервисе.
Три — мне показалось, или это так и есть, но автор рассматривал безопасность именно standalone docker нод
Очень интересно.
Сколько примерно по времени занимает такое тестирование?
Получается, его нужно накатывать на каждое изменение (=ежемесячно или чаще)?
Что делать, если необходимо протестировать какие-то специфические вещи — межпериодные выплаты, вроде больничных, отпусков, возврата 2ндфл и пр.?
Автоматизация присутствует? Очень интересно было бы почитать
У меня journal2gelf ломался на какой-то строчке лога… Не очень стабильная штука (((( fluent-bit с чтением напрямую из journald базы выглядит надежнее
Нормально там с безопасностью. Лог обогащается операционной системой метаданными, поэтому эти метки приложением не могут быть исковерканы.
DOCKER HEALTHCHECK абсолютно бесполезен. Аргументы?
А с ним я имел много приятных минут, когда он ломал деплой (ес-но — контейнер убивался, он его восстанавливал старой версии и все разваливалось).
А если через VPN? Если нужно — можно ужасы типа VDI без возможности скопипастить информацию + шпион на ноутбук сотрудника, что он гарантированно ничего не утащит.
Ну, и насколько я помню — там речь шла про обработку и хранение данных, так что кейс с ssh надуман. И еще — ведь можно же реплику держать вне ЕС? Можно.
Технические решения с разделением доступа нужны не только для того, чтобы обеспечить возможность работы условного Васи из Мухосранска. А скорее — для того, чтобы проходить комплайенс и показывать клиентам "какие мы крутые ребята — у нас все по процессам и безопасно". Заодно можно привлечь гос и окологос клиентов. То, что при это можно нанять Васю и он не сможет нанести вреда — только плюс.
Microsoft не бил себя ТОГДА пяткой в грудь, что они оплот опенсурса, демократии, отсутствия дискриминации… Возможно просто наши ожидания от ГитЛаба завышены. Не более.
Первое. Вы правда думаете, что какая-нибудь гос или окологос структура будет счастлива пользоваться облачным гитлабом (который gitlab.com)? Где ее данные и данные других клиентов перемешаны непонятно каким образом?
К этому же — если они все-таки берут он-премис инстанс, то как влияет местоположение разработчика на возможность заложить закладку в ПО? При наличии процесса код ревью (ответ — минимально).
Если у них он-премис — они (клиенты) могут вообще ПОТРЕБОВАТЬ физического нахождения сотрудника техпода на площадке. Или нет? Или это только в головах российских компаний, у которых "везде враги", а американцы сплошь в облаке сидят?
Второе — «second class of citizens» — это полный булшит. Всегда есть сотрудники с разным уровнем доступа. Как если сравнивать сотрудников на разных уровнях должностной лестницы (VP против сотрудника техпода), так и на примерно одинаковых уровных (у одного есть форма допуска к секретам, у другого — нет).
А чего тогда американским клиентам не потребовать того, чтобы их поддержкой (извините, накидываю) занимались белые гетеросексуальные американские граждане? Или поддержкой американцев могут заниматься только жители стран второго мира (ибо дешево)?
На самом деле проблема чисто в головах и в плоскости процессов. Гитлабу НИКТО не мешает устанавливать выделенные инстансы для американцев с паранойей (напр., госструктурам), которые будут обслуживать отдельные команды внутри компании. И об этом в комментах, кстати, писали.
Это тоже выглядит как глупость. Вот найдут они шестого суперталантливого разработчика — и что? Отказывать ему потому что он в России/Китае? А прикрываются мультикультурализмом и прочими общими местами. Короче, выглядит так, что ГитЛаб занимается зарабатыванием денег и все. Остальное по барабану.
Я бы так остро не реагировал, но это второй их серьезный прокол — первым был трекинг. Опять же — трекинг пользователей — это про зарабатывание $$$$, а не про… "делать хороший продукт"
Так же — как и обычно. Это не является какой-то гипер-сложной или непонятной, нерешаемой технической задачей. У них же есть внутри Gitlab-EE своя репликация (GitLab Geo), поэтому тем более не понимаю Ваших… недоумений.
Они имеют право делать так, но это… не по-человечески. Если так — им нужно сворачивать свой CE, в который вложились люди по всему миру, независимо от религии, места проживания и пр. атрибутов, и становиться полностью закрытой коммерческой организацией по типу Slack/Atlassian. Тогда бы вопросов не было. Но ожидания такие, что ГитЛаб — оплот опенсурса и соответственно должен вести себя так же.
Мечта была, но они ее таким образом окончательно убили.
Вероятно, что по экономическим причинам. Слишком высокие налоги и слишком лояльное к работнику трудовое законодательство?
Облако сложно. Во-первых, где гарантия, что спустя год, два, пять — облако не станет тыквой? Во-вторых — где гарантия, что Ваш условный архив домашнего видео облако не сольет куда-либо? В частности, если там может быть чувствительная информация. В принципе, это все решаемо — рассовыванием зашифрованных данных по нескольким облакам, но локальное хранилище проще. Но ОБЫЧНОМУ потребителю, который только и умеет, что в гуглопочту и вконтактик — облако проще.