Ну, я сразу в статье написал, что это про виртуалки, работающие в облаке, где очень много операций делается под капотом. Например, GCP умеет делать снапшоты дисков (и они даже консистентны, ну по крайней мере мы ни разу не натыкались, что они не были), автоматический консистентный бэкап managed базы. Железо у нас тоже есть, но данная концепция для него не годится.
Перекладывание проблемы на других? А я и не спорю и отвечу: ДА. Мы используем и Kubernetes как сервис, потому что это нас избавляет от большой мороки с железным кубером, хотя администрирования даже облачного кубера добавляет уйму работы. И это круто, потому что освобождает время для имплементации новых фичей, совершенствование инфры, внедрение новых технологий — а не постоянная поддержка инфры с невозможностью развиваться.
Что касается баз данных у нас была такая идея:
1. поднять клон базы данных прода — он консистентный
2. сделать снапшот данных прода и поднять новую виртуалку с новой версией приложения (старую не трогаем)
3. настроить и запустить приложение, приложение выполнит свои миграции на клоне бд и процедуру апгрейда локальных данных и тд
4. протестировать новый стейдж
5. если все ок, повторить первые 4 пункта еще раз, но выключив перед этим прод приложение (чтобы данные не обновлялись)
Я согласен, что задача без state лучше, чем задача со state. Это абсолютно верно, потому что так проще.
Но мы именно запускаем в Immutable Stateful сервисы, как с БД, так и с локальными стораджами. И вот это как раз самое интересное — как это реализовать в данной концепции. Если это локальный диск и приложение в единственном экземпляре, то есть варианты:
— выключить приложение, сделать снапшот диска, создать новый диск из снапшота, подключить его к новой виртуалке
— выключить старую виртуалку, подключить к новой виртуалке data диск
Конечно, все это через автоматизацию.
Что касается БД, я не зря оговорился про облако. Мы используем GCP CloudSQL — это managed MySQL, PostgreSQL и т.д. — то есть база вынесена наружу от приложения. И точно так же, как с data диском, мы можем клонировать CloudSQL инстанс с данными, поднимать для нее read реплику и промоутить в мастер и тд.
Мы не хотим каждый раз, когда мы хотим обновить Gitlab или Artifactory, поднимать базу и всю нужную инфру руками, чтобы протестировать обновление. Здесь нам помогает Immutable — мы можем получить копию прода в любой момент.
P.S. Подход подойдет и не только для инфра сервисов, но и для продуктов команд (приложений). Правда, там релизы чаще, и от даунтайма надо избавляться — здесь поможет лоад балансер, трансформация разработки и тд.
Да, согласен.
У нас приоритет — запуск приложения в GKE. Но не всегда GKE подойдет, особенно в случаях если:
Вам не подойдет GKE, если ваше приложение соответствует любому из этих пунктов:
— Приложение не может быть докеризовано
— Приложению необходимо очень много ресурсов CPU и RAM
— Приложение не может быть портировано или запущено в GKE по какой-то причине
— Это база данных (тут мы предпочитаем использовать бд как сервис, но не всегда это прокатывает)
Кроме того, мы разворачиваем различные инфраструктурные сервисы в Immutable манере:
— Artifactory (мы не можем запустить его в кубах, потому что от него зависят кубы — с него пулятся docker образы)
— Gitlab (мы не можем запустить его в кубах, потому что официальный helm чарт не поддерживал работу Gitlab Pages)
— Sentry (у них поставка приложения происходит через docker-compose, очень много компонентов, clickhouse, redis, БД и тд, и нам показалось проще запустить это на виртуалке)
— Aptly (если не ошибаюсь, с докером тоже не вышло)
Но Immutable отлично подойдет для Stateless приложений. Хотя для нас интереснее Stateful, потому что все сервисы выше как раз имеют State и БД. А Stateless запускать в Immutable сам бог велел — только сделай образ и конфигуратор)
Возможно, неточно сформулировал. Туннели из разных регионов начали падать одновременно. Такое ощущение, что кто-то нажимал рубильник в Китае.
Когда продукт состоит из многих-многих микросервисов, огромных баз данных и жирных бэкэндов, не идет речи вообще о их переносе в Китай. Да в принципе куда бы то ни было. Понятно, что небольшие сервисы можно разместить в Китае, но большие бэкэнды привязаны к месту дислокации, так что решение прохода фаервола все равно будет нужно в любом случае.
Спасибо за вопрос! На самом деле, никаких возможностей веб-проект не потеряет, последствий не будет. Единственное, что может случится — затруднится работа маркетологов, которые изучают Ваши сайты с помощью SEMrush. Им будет видно меньше данных по сайту. В частности, это касается бэклинок, ведущих с него и на него. В остальном ничего не изменится.
Боюсь, что там будет то еще решето, что его и пробивать не нужно будет. Я сомневаюсь, что у нас будет создано что-то типа такого фаервола, чтобы оно работало на таком же уровне (надо признать, что функции свои он выполняет довольно хорошо).
Скорее всего, просто сломают интернет у нас когда-нибудь. Интернет — я имею ввиду доступ забугор.
Платный ExpressVPN у меня работал через пень-колоду. Сложно было на него полагаться. На мобильном интернете вообще все было плохо (я использовал местную SIM-карту, но про то, как она получается — это вообще отдельный разговор. Могу немного рассказать, если интересно). Бесплатные сервисы не работали вообще.
Про ICP отвечу вам так: мы получали лицензию через партнеров, которых посоветовал нам Cloudflare. ICP зарубежным гражданам в принципе не получить, если не ошибаюсь. Поэтому либо регистрируешь бизнес в Китае (это сложно), либо оформляешь лицензию через партнеров (это попроще, но есть нюансы).
В статьях про особенность получения ICP-лицензии все написано довольно правдиво и правильно. Почитайте. Я не стал раскрывать эту тему, потому что не особо занимался этим моментом.
Подтверждаю, лучше всех себя в Китае показал VPN типа L2TP+IPsec. Работал довольно стабильно и быстро. Я также пользовался ExpressVPN и подключался к разным локациям. Лучше всего работал Гонконг и Токио, но периодически все ломалось. Там постоянная игра в кошки-мышки идет, на сколько я понимаю. Власти блокируют VPN, ребята делают новые — и по новой.
По поводу своей VPS — расскажу такую историю. У чувака был свой сервер заграницей, он приехал в Китай, подклчюился к нему — все летает. В течение суток IP был заблокирован, и его VPN превратился в тыкву. Так что там не слишком зависит от трафика на IP. Блокируется в принципе все, просто со временем. Но L2TP+IPsec вроде бы работает дольше
Как интересно. Описанный баг с AAAA-записью имел место быть в августе 2018-го. В статье я привел практически цитату ребят из Cloudflare, которую не утрудил себя проверить на сегодняшний момент. А тогда такой ответ нас полностью устроил :)
Беглый поиск показал, что судя по всему, IPv6 в Китае начал развиваться как раз в 2018-2019 годах. Возможно, на тот момент времени с IPv6 там было совсем все плохо. Трудно сказать.
Но круто, что у вас сейчас работает! Спасибо, что написали
Чтобы использовать возможности Cloudflare, много ума не надо, поэтому ошибиться там сложно.
Дело в том, что Cloudflare как CDN-провайдер работал неплохо. Да, агрегировал трафик в своих точках присутствия. Да, присутствовал во многих регионах. Да, был anycast. Но, нет, не было чудесного прохода китайского фаервола (ведь как-то же надо попасть на наши origin-сервера на восточном побережье США), на который мы так рассчитывали. Ко всему еще и проблема с DNS приключилась. А после фикса, latency DNS-запросов никуда не делась и продолжала играть роль в тестах.
China Network — далеко не бесплатная фича Cloudflare. И если по итогу мы получаем просто работающий CDN, то непонятно, зачем это нужно, ведь есть и другие CDN-провайдеры в Китае. Китайские CDN — интересная часть нашего исследования. Будет во 2й или 3й части.
Спасибо за инфу, про hiera-file почитаю, как и про octocatalog-diff.
У нас проблема с модулями решается тем, что в Puppetfile для всех удаленных модулях мы указываем требуемую версию модуля. Это несколько нивелирует мои высокопарные фразы про то, что удаленные модули круто использовать, потому что они обновляются, но такова жизнь) Просто если что-то сломалось (обновили ОС на сервере), можно удобно глянуть в проект модуля и понять, был ли пофикшен какой-то баг. И если да, обновить версию модуля (проверив перед этим все конечно).
Кастомные файлы можно создавать как при сетапе сервера (мы используем Maas), так и руками.
Да, мы используем кастомные факты. В папку /opt/puppetlabs/facter/facts.d/ кладутся файлы типа /opt/puppetlabs/facter/facts.d/team.txt с содержимым: team=admin
Кроме того, факты можно задать непосредственно через запуск паппет агента: FACTER_team=admin puppet agent -t
Тогда агент при прогоне сам создаст нужный файл факта и применит соотвествующую конфигурацию.
Данные факты мы выставляем не на основе fqdn, как вы, а в соответствии с:
— какой команде делаем сервер?
— что это за проект? (если есть)
— какая роль у сервера? (если есть)
— какой стейджинг? (если нужно и есть)
Ну то есть мы это узнаем у заказчиков серверов, либо делаем новую иерархию, если до этого подобное не описывалось.
Можно использовать коллекторы ресурсов , или, как сказал выше tamaki, require, before, after и т.д.
Но с коллекторами надо быть аккуратным, благодаря ним можно попасть в dependency loop.
Даже в картинке выше указана данная проблема в шуточной форме: пакеты приехали раньше репозиториев. Но, на мой взгляд, это не прям уж критично. Ну попытается пакет поставиться до накатки репозитория, один run зафейлится, в следующий все ок будет. При фейле паппет же не прекращает работу, а продолжает применять оставшуюся часть каталога.
Мы не используем паппет в виде демона, а запускаем его по крону. Грубо говоря, реальные ошибки по неправильным последовательностям применения ресурсов может быть только при первоначальном сетапе сервера и последующего первого запуска паппета. Сервера деплоятся автоматически, паппет на них первый раз запускается тоже «сам». В течение 20 минут он гарантированно разрулит все фейлы и применит-таки конфигурацию, запустившись пару раз по крону.
Неа, не рассматривали, но я посмотрю в сторону этих тулз. Спасибо за наводку)
Перекладывание проблемы на других? А я и не спорю и отвечу: ДА. Мы используем и Kubernetes как сервис, потому что это нас избавляет от большой мороки с железным кубером, хотя администрирования даже облачного кубера добавляет уйму работы. И это круто, потому что освобождает время для имплементации новых фичей, совершенствование инфры, внедрение новых технологий — а не постоянная поддержка инфры с невозможностью развиваться.
Что касается баз данных у нас была такая идея:
1. поднять клон базы данных прода — он консистентный
2. сделать снапшот данных прода и поднять новую виртуалку с новой версией приложения (старую не трогаем)
3. настроить и запустить приложение, приложение выполнит свои миграции на клоне бд и процедуру апгрейда локальных данных и тд
4. протестировать новый стейдж
5. если все ок, повторить первые 4 пункта еще раз, но выключив перед этим прод приложение (чтобы данные не обновлялись)
Но мы именно запускаем в Immutable Stateful сервисы, как с БД, так и с локальными стораджами. И вот это как раз самое интересное — как это реализовать в данной концепции. Если это локальный диск и приложение в единственном экземпляре, то есть варианты:
— выключить приложение, сделать снапшот диска, создать новый диск из снапшота, подключить его к новой виртуалке
— выключить старую виртуалку, подключить к новой виртуалке data диск
Конечно, все это через автоматизацию.
Что касается БД, я не зря оговорился про облако. Мы используем GCP CloudSQL — это managed MySQL, PostgreSQL и т.д. — то есть база вынесена наружу от приложения. И точно так же, как с data диском, мы можем клонировать CloudSQL инстанс с данными, поднимать для нее read реплику и промоутить в мастер и тд.
Мы не хотим каждый раз, когда мы хотим обновить Gitlab или Artifactory, поднимать базу и всю нужную инфру руками, чтобы протестировать обновление. Здесь нам помогает Immutable — мы можем получить копию прода в любой момент.
P.S. Подход подойдет и не только для инфра сервисов, но и для продуктов команд (приложений). Правда, там релизы чаще, и от даунтайма надо избавляться — здесь поможет лоад балансер, трансформация разработки и тд.
У нас приоритет — запуск приложения в GKE. Но не всегда GKE подойдет, особенно в случаях если:
Вам не подойдет GKE, если ваше приложение соответствует любому из этих пунктов:
— Приложение не может быть докеризовано
— Приложению необходимо очень много ресурсов CPU и RAM
— Приложение не может быть портировано или запущено в GKE по какой-то причине
— Это база данных (тут мы предпочитаем использовать бд как сервис, но не всегда это прокатывает)
Кроме того, мы разворачиваем различные инфраструктурные сервисы в Immutable манере:
— Artifactory (мы не можем запустить его в кубах, потому что от него зависят кубы — с него пулятся docker образы)
— Gitlab (мы не можем запустить его в кубах, потому что официальный helm чарт не поддерживал работу Gitlab Pages)
— Sentry (у них поставка приложения происходит через docker-compose, очень много компонентов, clickhouse, redis, БД и тд, и нам показалось проще запустить это на виртуалке)
— Aptly (если не ошибаюсь, с докером тоже не вышло)
Но Immutable отлично подойдет для Stateless приложений. Хотя для нас интереснее Stateful, потому что все сервисы выше как раз имеют State и БД. А Stateless запускать в Immutable сам бог велел — только сделай образ и конфигуратор)
Когда продукт состоит из многих-многих микросервисов, огромных баз данных и жирных бэкэндов, не идет речи вообще о их переносе в Китай. Да в принципе куда бы то ни было. Понятно, что небольшие сервисы можно разместить в Китае, но большие бэкэнды привязаны к месту дислокации, так что решение прохода фаервола все равно будет нужно в любом случае.
Видимо, да.
Скорее всего, просто сломают интернет у нас когда-нибудь. Интернет — я имею ввиду доступ забугор.
Платный ExpressVPN у меня работал через пень-колоду. Сложно было на него полагаться. На мобильном интернете вообще все было плохо (я использовал местную SIM-карту, но про то, как она получается — это вообще отдельный разговор. Могу немного рассказать, если интересно). Бесплатные сервисы не работали вообще.
Возможно, зависит еще от провинции и города.
Про ICP отвечу вам так: мы получали лицензию через партнеров, которых посоветовал нам Cloudflare. ICP зарубежным гражданам в принципе не получить, если не ошибаюсь. Поэтому либо регистрируешь бизнес в Китае (это сложно), либо оформляешь лицензию через партнеров (это попроще, но есть нюансы).
В статьях про особенность получения ICP-лицензии все написано довольно правдиво и правильно. Почитайте. Я не стал раскрывать эту тему, потому что не особо занимался этим моментом.
Или используйте Wechat Videos :)
По поводу своей VPS — расскажу такую историю. У чувака был свой сервер заграницей, он приехал в Китай, подклчюился к нему — все летает. В течение суток IP был заблокирован, и его VPN превратился в тыкву. Так что там не слишком зависит от трафика на IP. Блокируется в принципе все, просто со временем. Но L2TP+IPsec вроде бы работает дольше
Беглый поиск показал, что судя по всему, IPv6 в Китае начал развиваться как раз в 2018-2019 годах. Возможно, на тот момент времени с IPv6 там было совсем все плохо. Трудно сказать.
Но круто, что у вас сейчас работает! Спасибо, что написали
Дело в том, что Cloudflare как CDN-провайдер работал неплохо. Да, агрегировал трафик в своих точках присутствия. Да, присутствовал во многих регионах. Да, был anycast. Но, нет, не было чудесного прохода китайского фаервола (ведь как-то же надо попасть на наши origin-сервера на восточном побережье США), на который мы так рассчитывали. Ко всему еще и проблема с DNS приключилась. А после фикса, latency DNS-запросов никуда не делась и продолжала играть роль в тестах.
China Network — далеко не бесплатная фича Cloudflare. И если по итогу мы получаем просто работающий CDN, то непонятно, зачем это нужно, ведь есть и другие CDN-провайдеры в Китае. Китайские CDN — интересная часть нашего исследования. Будет во 2й или 3й части.
У нас проблема с модулями решается тем, что в Puppetfile для всех удаленных модулях мы указываем требуемую версию модуля. Это несколько нивелирует мои высокопарные фразы про то, что удаленные модули круто использовать, потому что они обновляются, но такова жизнь) Просто если что-то сломалось (обновили ОС на сервере), можно удобно глянуть в проект модуля и понять, был ли пофикшен какой-то баг. И если да, обновить версию модуля (проверив перед этим все конечно).
Да, мы используем кастомные факты. В папку /opt/puppetlabs/facter/facts.d/ кладутся файлы типа /opt/puppetlabs/facter/facts.d/team.txt с содержимым:
team=adminКроме того, факты можно задать непосредственно через запуск паппет агента:
FACTER_team=admin puppet agent -tТогда агент при прогоне сам создаст нужный файл факта и применит соотвествующую конфигурацию.
Данные факты мы выставляем не на основе fqdn, как вы, а в соответствии с:
— какой команде делаем сервер?
— что это за проект? (если есть)
— какая роль у сервера? (если есть)
— какой стейджинг? (если нужно и есть)
Ну то есть мы это узнаем у заказчиков серверов, либо делаем новую иерархию, если до этого подобное не описывалось.
Но с коллекторами надо быть аккуратным, благодаря ним можно попасть в dependency loop.
Даже в картинке выше указана данная проблема в шуточной форме: пакеты приехали раньше репозиториев. Но, на мой взгляд, это не прям уж критично. Ну попытается пакет поставиться до накатки репозитория, один run зафейлится, в следующий все ок будет. При фейле паппет же не прекращает работу, а продолжает применять оставшуюся часть каталога.
Мы не используем паппет в виде демона, а запускаем его по крону. Грубо говоря, реальные ошибки по неправильным последовательностям применения ресурсов может быть только при первоначальном сетапе сервера и последующего первого запуска паппета. Сервера деплоятся автоматически, паппет на них первый раз запускается тоже «сам». В течение 20 минут он гарантированно разрулит все фейлы и применит-таки конфигурацию, запустившись пару раз по крону.