For the overlay2 storage driver, the size option is only available if the backing fs is xfs and mounted with the pquota mount option. Under these conditions, user can pass any size less than the backing fs size.
Вообще я ожидаю от разработчика, что его приложение вообще не пишет ничего в свою контейнерную файловую систему. Если уж нужно что-то писать, то для этого подключаются волюмы.
Ну во-первых это был один из staging'ов. Во-вторых как я сказал, проблема не в ротации логов, а в том что контейнер заполнил файловую систему которую ему выделили. 10G лимит распространяется только на devicemapper, в случае overlay2 лимитов нет.
Спасибо за статью, жизненно.
Вашим бы списком да по нашим ребятам из dev'а…
Я просто тут как раз занимался процессом принятия кучи микросервисов из dev-окружения в production Kubernetes, и прямо вот из ваших 22 кажется пунктов были на месте от силы 4, и это боль, да. Кину им английскую версию почитать :)
Вот про «Все логи пишутся в STDOUT/STDERR» еще добавлю: оно еще важно не только с точки зрения однообразия и удобства, но и использования места на диске — у нас так один микросервис со «случайно» включенным DEBUG режимом за короткое время заполнил всю файловую систему /var/lib/docker, просто потому что писал логи в файл внутри контейнера. И главное в такой ситуации log rotation самого докера не поможет никак.
То есть стоит продемонстрировать поведение, непохожее на компьютер — и его сразу объявят мышлением?
На самом деле мне вспомнилось какое-то рассуждение о том, что пока созданные нами вещи (автомобили, компьютеры) ведут себя так, как мы ожидаем — мы не их не наделяем никакими способностями, но вот стоит им начать вести себя немного непредсказуемо (авто не заводится, комп завис), и мы начинаем даже разговаривать с ними ("будь проклят тот день когда я сел за баранку этого пылесоса" ;) — мы наделяем их "сознанием". По-моему, довольно интересное наблюдение.
Еще и поэтому критикуют тест Тьюринга — этот тест не определяет, может ли машина мыслить, а он определяет, может ли она имитировать человеческое поведение.
Поэтому когда говрят в быту что машина мыслит часто имеют в виду что она демонстрирует поведение похожее на человеческое (== нетипичное для машин).
конечно, не спорю.
Просто хелм — это сообщество и репозиторий чартов, что иногда освобождает от велосипедостроения.
Это как с контейнерами — можно разные рантаймы юзать, но докер популярен из-за репозитория открытых образов.
Но вот только проблема цензуры в том, что она может стать неуправляемой, и такой подход становится антинаучным по сути (так же как ненаучно было бы заявить: «бога 100% не существует»; мы можем лишь утверждать, что с большой вероятностью его нет, более того мы обязаны быть готовыми принять обратное, если оно будет доказано когда-либо).
И мы, как представители научного сообщества, оказываемся изначально в положении, обязывающем нас играть строго по правилам науки, и, нарушая эти правила, мы теряем саму сущность науки. Это все равно что устанавливать демократию с помощью насилия.
Вот эту беспомощность просвещенного человека среди темных масс прекрасно описали Стругацкие в книге «Трудно быть богом». Да, видеть все это невыносимо, но бороться только гуманными и научными средствами.
Спасибо за статью!
А вот еще рядом с научпопом можно назвать научную фантастику, которая (будучи качественной) может стать для кого-то входом в науку, несколько более «лайтовым», чем научпоп. Но тут выбирать контент следует еще более тщательно, конечно.
Как хороший пример могу назвать любимых мной Стругацких, из современников Горькавый мне понравился. Но за строгую научность содержания не могу отвечать, может кто прокомментирует.
В реальном мире нет никаких учебников или учебных планов. Нет возможности практиковаться. Нет источника постоянной обратной связи. Нет учителей – есть только вы, и те люди, которых вы можете убедить помогать вам.
Я бы вот тут еще добавил: мне, например, в реальном мире не хватает еще от школьного/университетского образования конкуренции и поощрений в виде оценок/рейтингов/стипендий. Я знаю, что для некоторых людей (меня, например) это может быть очень сильной мотивацией изучить что-то хорошо — стать лучшим среди кого-то. Ну правда я сейчас вот подумал, что существуют хакатоны, пожалуй это как раз некоторая такая альтернатива.
у меня такой вопрос: а как считались коммиты для MySQL, если git существует только с 2005 года? а предыдущие 10 лет разработки MySQL как учитывались? или они какую-то другую vcs использовали до того?
кстати так и не понял за что провинилось BSD если все было автоматизировано
…
Я уверен, что там люди могли и сопровождать, и реструктуризировать систему
так дело ведь не в том, что там сейчас все круто, а в том, кто все это потом будет поддерживать, когда эти админы уйдут. Наверняка найти людей которые готовы сопровождать популярные дистрибутивы линукса проще, чем тех, кто разбирается в BSD.
Тут всегда вопрос баланса между "красивым" решением и "поддерживаемым". Мне вот часто приходится бить себя по рукам, когда я в порыве стремления к красоте и автоматизации хочу написать как можно лаконичнее — можно в том же баше весь скрипт упихать в одну строку с пайпами: красота, наслаждение! Но совершенно нечитабельно, и поэтому лучше развернуть в несколько строк с циклами, и комментов добавить. Питонисты тоже иногда подобным могут увлекаться)
Я вот тут недавно писал логику для gitlab-ci файла и мне понадобились динамичные имена переменных. Ну, первая мысль, конечно — eval. И тут я натолкнулся на замечательный коммент на StackOverflow:
В итоге я добился того, чего хотел, у меня получилось два вложенных eval'а, все красиво, все работает. Я посмотрел на все это, понаслаждался своим творением, потом подумал о тех, кто будет после меня это поддерживать, стер все нафиг и написал заново по-человечески. Да, получилось больше кода. Но зато это смогут прочитать и быстро понять ребята из dev отдела и тот парень, который после меня когда-то придет править этот файл.
Да, спасибо, я тоже думал сначала про локальную базу. Единственное, встает тогда вопрос с ее обновлением — хотя, опять же, для грубой оценки геолокаций клиентов наверное это не столь критично…
Хотелось бы от себя добавить: возможно после прочтения статьи кто-то захочет выставить значение --iptables-sync-period как можно меньше, скажем равным 1 сек, чтобы правила почаще обновлялись и не было задержки в случае случайного удаления правил iptables.
Так вот, тут нужно понимать что kube-proxy каждые 30 сек запрашивает у api список сервисов и запускает цикл в котором проверяет соответствие правил желаемому состоянию. И в случае большого количества сервисов этот цикл будет выполняться долго, плюс для каждого сервиса в NAT таблице создается не одно правило а несколько, в зависимости от кол-ва IP адресов у сервиса.
У этого дизайна (все правила на всех нодах) есть и побочная сторона — представьте что у вас кластер из 1000 нод (Kubernetes поддерживает до 5000), и у вас скажем 5000 сервисов, что не так уж много для такого кластера. Тогда во-первых на каждой ноде будут длинные портянки в NAT таблицах, а самое главное что kube-proxy просто сожрет весь CPU ресурс обходя бесконечно все сервисы. Вот здесь есть очень показательные графики поведения iptables и ipvs при возрастании количества сервисов.
Ну и кроме того в недрах Рамблера родился nginx, на котором сейчас пол веба работает
Еще точнее так, из документации:
Вообще я ожидаю от разработчика, что его приложение вообще не пишет ничего в свою контейнерную файловую систему. Если уж нужно что-то писать, то для этого подключаются волюмы.
Ну во-первых это был один из staging'ов. Во-вторых как я сказал, проблема не в ротации логов, а в том что контейнер заполнил файловую систему которую ему выделили. 10G лимит распространяется только на
devicemapper, в случаеoverlay2лимитов нет.Вашим бы списком да по нашим ребятам из dev'а…
Я просто тут как раз занимался процессом принятия кучи микросервисов из dev-окружения в production Kubernetes, и прямо вот из ваших 22 кажется пунктов были на месте от силы 4, и это боль, да. Кину им английскую версию почитать :)
Вот про «Все логи пишутся в STDOUT/STDERR» еще добавлю: оно еще важно не только с точки зрения однообразия и удобства, но и использования места на диске — у нас так один микросервис со «случайно» включенным DEBUG режимом за короткое время заполнил всю файловую систему /var/lib/docker, просто потому что писал логи в файл внутри контейнера. И главное в такой ситуации log rotation самого докера не поможет никак.
На самом деле мне вспомнилось какое-то рассуждение о том, что пока созданные нами вещи (автомобили, компьютеры) ведут себя так, как мы ожидаем — мы не их не наделяем никакими способностями, но вот стоит им начать вести себя немного непредсказуемо (авто не заводится, комп завис), и мы начинаем даже разговаривать с ними ("будь проклят тот день когда я сел за баранку этого пылесоса" ;) — мы наделяем их "сознанием". По-моему, довольно интересное наблюдение.
Еще и поэтому критикуют тест Тьюринга — этот тест не определяет, может ли машина мыслить, а он определяет, может ли она имитировать человеческое поведение.
Поэтому когда говрят в быту что машина мыслит часто имеют в виду что она демонстрирует поведение похожее на человеческое (== нетипичное для машин).
конечно, не спорю.
Просто хелм — это сообщество и репозиторий чартов, что иногда освобождает от велосипедостроения.
Это как с контейнерами — можно разные рантаймы юзать, но докер популярен из-за репозитория открытых образов.
В конце концов хелм хорош как шаблонизатор + репозиторий (полу)готовых чартов.
Все остальное решается
helm template . | kubectl apply -f -и CI/CD.Совершенно разделяю вашу эмоцию!
Но вот только проблема цензуры в том, что она может стать неуправляемой, и такой подход становится антинаучным по сути (так же как ненаучно было бы заявить: «бога 100% не существует»; мы можем лишь утверждать, что с большой вероятностью его нет, более того мы обязаны быть готовыми принять обратное, если оно будет доказано когда-либо).
И мы, как представители научного сообщества, оказываемся изначально в положении, обязывающем нас играть строго по правилам науки, и, нарушая эти правила, мы теряем саму сущность науки. Это все равно что устанавливать демократию с помощью насилия.
Вот эту беспомощность просвещенного человека среди темных масс прекрасно описали Стругацкие в книге «Трудно быть богом». Да, видеть все это невыносимо, но бороться только гуманными и научными средствами.
Спасибо за статью!
А вот еще рядом с научпопом можно назвать научную фантастику, которая (будучи качественной) может стать для кого-то входом в науку, несколько более «лайтовым», чем научпоп. Но тут выбирать контент следует еще более тщательно, конечно.
Как хороший пример могу назвать любимых мной Стругацких, из современников Горькавый мне понравился. Но за строгую научность содержания не могу отвечать, может кто прокомментирует.
#!/bin/спасибо за статью, очень понравилось!
Я бы вот тут еще добавил: мне, например, в реальном мире не хватает еще от школьного/университетского образования конкуренции и поощрений в виде оценок/рейтингов/стипендий. Я знаю, что для некоторых людей (меня, например) это может быть очень сильной мотивацией изучить что-то хорошо — стать лучшим среди кого-то. Ну правда я сейчас вот подумал, что существуют хакатоны, пожалуй это как раз некоторая такая альтернатива.
у меня такой вопрос: а как считались коммиты для MySQL, если git существует только с 2005 года? а предыдущие 10 лет разработки MySQL как учитывались? или они какую-то другую vcs использовали до того?
так дело ведь не в том, что там сейчас все круто, а в том, кто все это потом будет поддерживать, когда эти админы уйдут. Наверняка найти людей которые готовы сопровождать популярные дистрибутивы линукса проще, чем тех, кто разбирается в BSD.
Тут всегда вопрос баланса между "красивым" решением и "поддерживаемым". Мне вот часто приходится бить себя по рукам, когда я в порыве стремления к красоте и автоматизации хочу написать как можно лаконичнее — можно в том же баше весь скрипт упихать в одну строку с пайпами: красота, наслаждение! Но совершенно нечитабельно, и поэтому лучше развернуть в несколько строк с циклами, и комментов добавить. Питонисты тоже иногда подобным могут увлекаться)
Я вот тут недавно писал логику для
gitlab-ciфайла и мне понадобились динамичные имена переменных. Ну, первая мысль, конечно —eval. И тут я натолкнулся на замечательный коммент на StackOverflow:В итоге я добился того, чего хотел, у меня получилось два вложенных
eval'а, все красиво, все работает. Я посмотрел на все это, понаслаждался своим творением, потом подумал о тех, кто будет после меня это поддерживать, стер все нафиг и написал заново по-человечески. Да, получилось больше кода. Но зато это смогут прочитать и быстро понять ребята из dev отдела и тот парень, который после меня когда-то придет править этот файл.Хороший перевод, спасибо!
Хотелось бы от себя добавить: возможно после прочтения статьи кто-то захочет выставить значение
--iptables-sync-periodкак можно меньше, скажем равным 1 сек, чтобы правила почаще обновлялись и не было задержки в случае случайного удаления правил iptables.Так вот, тут нужно понимать что kube-proxy каждые 30 сек запрашивает у api список сервисов и запускает цикл в котором проверяет соответствие правил желаемому состоянию. И в случае большого количества сервисов этот цикл будет выполняться долго, плюс для каждого сервиса в NAT таблице создается не одно правило а несколько, в зависимости от кол-ва IP адресов у сервиса.
У этого дизайна (все правила на всех нодах) есть и побочная сторона — представьте что у вас кластер из 1000 нод (Kubernetes поддерживает до 5000), и у вас скажем 5000 сервисов, что не так уж много для такого кластера. Тогда во-первых на каждой ноде будут длинные портянки в NAT таблицах, а самое главное что kube-proxy просто сожрет весь CPU ресурс обходя бесконечно все сервисы. Вот здесь есть очень показательные графики поведения iptables и ipvs при возрастании количества сервисов.