Зачем платить за 1 core 1 ram и использовать какого-то непонятного провайдера для тестов, если в,можно сказать,эталонном AWS это free tier? :)
Вместо Prometheus лучше использовать VictoriaMetrics, который менее требователен к ресурсам и более шустр + умеет нормально долго хранить метрики (если это конечно нужно) и много что ещё. Для некоторых моих проектов полностью заменил Prometheus in place, т.е. Grafana с ним работает как с Prometheus без дополнительных настроек.
В общей сложности я пытался решить эту задачку один месяц. В итоге я прекратил все попытки и отказался от сфер. Возможно, пост на форуме рендера помог бы, но я ограничился помощью русскоязычного сообщества — до кого мог дотянуться.
Никогда не стоит ограничиваться русскоязычным сообществом потому что оно гораздо меньше мирового. Даже если у вас проблема с английским, то использовать тот же Google translate встроенный в Chrome гораздо лучше, чем ограничивать себе возможности.
Пытаться решить задачу месяц для меня звучит, как крайне долго.
Рекомендую обратить внимание на https://github.com/peak/s5cmd который конечно не является решением из коробки, но в некоторых случаях значительно быстрее любого другого решения.
Cicd используется для всяческих автоматизации и для адресов которые могут находиться где угодно, даже на домашних машинах, где может стоять прокси и пересылать трафик в любое место.
Не вижу решения, кроме как блокировка трафика по сигнатуре.
И что будет в whitelist? Весь GitHub, Dockerhub и т.д.? А смысл? Весь код и так там. Создаётся новый репозиторий, в него заливается что угодно и вперёд.
Быстрый обмен даже не всегда нужен, т.к. при майнинге часто можно получить задачу, поработать над ней и потом её результат уже отправлять обратно в пул.
Ситуация конечно далека от идеальной как и этот мир и инструменты вроде driftctl и в целом такое понятие, как infra drift появились не просто так.
Но мне нравится как вы излагаете, потому что DevOps это как раз не про написание инструментов, а про продвижение правильной культуры в организации и про пробитие определённых в том числе административных барьеров. Много раз видел когда куча технически грамотных людей пилят какую-то чепуху даже не потому что продукт такой, а потому что нет воли, желания и т.п. менять культуру в организации и они очевидно хотят просто тихо сидеть на своём месте и спокойно получать зарплату не развиваясь. Имхо DevOps должен быть двигателем и спокойная жизнь это не про DevOps. Поэтому многие люди, которые пришли в DevOps из системного администрирования, но работаю просто как продвинутые системные администраторы, которые умеют немного программировать, на самом деле не являются DevOps'ами ещё и потому, что работают в разных с культурой DevOps, как её понимаю я, парадигмах.
В этом конкретном случае организация, к сожалению, никак не готова согласиться на запрет этих ручных изменений.
Crossplane отличный инструмент, знаю его, но я имел ввиду (возможно выразился не совсем точно) именно про работающие с Terraform инструменты, которые можно было бы использовать с этой задачей.
Запретить, конечно, было бы здорово, но, к сожалению, часто встречается, что некоторым запретить доступ через UI или какие-то другие инструменты нельзя.
На самом питон тут вообще не нужен, т.к. aws cli ставит свой, а несколько остальных утилит просто не используются.
Но в рамках уже написанного можно использовать установленное совершенно без проблем.
Вообще люблю я эти shyaml, jq, yq, envsubst и т.д. Места много не занимают, а автоматизации вполне хорошо помогают, удобно иметь их в случае чего.
Когда даёте советы убедитесь, что они сами соответствуют best practices :)
Чтобы покопаться в слоях, мало ли не знаете и вам интересно, есть прикольная штука (таких много есть, но эта нравится): github.com/wagoodman/dive
Так-то у Terraform / Terragrunt и свои уже собранные контейнеры есть и собирать свой в целом смысла почти нет.
По-поводу python3-dev и build-essential принимаю, но лень мне было из-за несчастного aws cli делать multistage, к тому же у меня работает несколько другой контейнер. Плюс вам поставить пока не могу из-за недостатка кармы.
Ещё раз перечитайте первую строку моего предыдущего комментария и не набрасывайте, смысл статьи не показать все best practices, а с близкой к максимальной скорости реализовать автоматизацию.
И всё же ссылка по использованию ADD, которую я привёл даже в названии имеет dockerfile best practices, вы можете делать как угодно. Лично мне больше нравится именно curl или wget'ом делать такое, пускай это ещё + утилита. А так конечно нужно билдить отдельно, потом перекладывать в from scratch и т.п.
Я чуть было не положил в cloud-init такое: apt update
apt install -y cargo
cargo install prometheus_wireguard_exporter
Потом подумал, что народ попытаясь это развернуть заждётся пока Rust это соберёт и всё-таки выложил бинарник. Точнее я раскатал это на t2.medium, заждался, сбилдил у себя на i9 и выложил бинарь :)
Возможно и сподоблюсь что-то написать.
Мне лично их документация тоже не нравится, как-то лично на мой вкус сложно всё ищется, если искать не натравливая гугл на неё и stackoverflow, а прямо в ней.
Я потому и написал «За код не ругайте, написал за несколько часов и решил поделиться.»
Тут очень много что можно исправить, а цель статьи в том, чтобы показать, что можно сесть и автоматизировать что-то за пару часов. Потом, естественно, рефакторить.
Because image size matters, using ADD to fetch packages from remote URLs is strongly discouraged; you should use curl or wget instead. That way you can delete the files you no longer need after they’ve been extracted and you don’t have to add another layer in your image. For example, you should avoid doing things like: ADD https://example.com/big.tar.xz /usr/src/things/
RUN tar -xJf /usr/src/things/big.tar.xz -C /usr/src/things
RUN make -C /usr/src/things all
And instead, do something like:
RUN mkdir -p /usr/src/things \
&& curl -SL https://example.com/big.tar.xz \
| tar -xJC /usr/src/things \
&& make -C /usr/src/things all
For other items (files, directories) that do not require ADD’s tar auto-extraction capability, you should always use COPY
Я говорю о бизнес проектах и просчитывать бизнес риски, в том числе политические, нужно заблаговременно и строить архитектуру проекта с их учётом обязательно.
Боязнь облаков свойственна больше Российским проектам, т.к. видимо, здесь политические риски несколько выше.
Но serverless на мой взгляд, это всё же про облака, поэтому если у вашего проекта есть политические риски, то вероятно лучше использовать другую технологию, благо на serverless свет клином не сошёлся.
Зачем платить за 1 core 1 ram и использовать какого-то непонятного провайдера для тестов, если в,можно сказать,эталонном AWS это free tier? :)
Вместо Prometheus лучше использовать VictoriaMetrics, который менее требователен к ресурсам и более шустр + умеет нормально долго хранить метрики (если это конечно нужно) и много что ещё. Для некоторых моих проектов полностью заменил Prometheus in place, т.е. Grafana с ним работает как с Prometheus без дополнительных настроек.
Никогда не стоит ограничиваться русскоязычным сообществом потому что оно гораздо меньше мирового. Даже если у вас проблема с английским, то использовать тот же Google translate встроенный в Chrome гораздо лучше, чем ограничивать себе возможности.
Пытаться решить задачу месяц для меня звучит, как крайне долго.
Рекомендую обратить внимание на https://github.com/peak/s5cmd который конечно не является решением из коробки, но в некоторых случаях значительно быстрее любого другого решения.
100Gbps вам хватит? :)
P.S. у Амазона легкогуглящиеся подробные доки
https://aws.amazon.com/ru/premiumsupport/knowledge-center/s3-maximum-transfer-speed-ec2/#:~:text=Traffic%20between%20Amazon%20EC2%20and,IPs%20in%20the%20same%20Region.
Cicd используется для всяческих автоматизации и для адресов которые могут находиться где угодно, даже на домашних машинах, где может стоять прокси и пересылать трафик в любое место.
Не вижу решения, кроме как блокировка трафика по сигнатуре.
И что будет в whitelist? Весь GitHub, Dockerhub и т.д.? А смысл? Весь код и так там. Создаётся новый репозиторий, в него заливается что угодно и вперёд.
Быстрый обмен даже не всегда нужен, т.к. при майнинге часто можно получить задачу, поработать над ней и потом её результат уже отправлять обратно в пул.
Cicd с такими задержками не рабочий инструмент
Kubernetes за 60 минут — это долго. Возможно это облако mail.ru такое неспешное, но чтобы настолько? :)
Ситуация конечно далека от идеальной как и этот мир и инструменты вроде driftctl и в целом такое понятие, как infra drift появились не просто так.
Но мне нравится как вы излагаете, потому что DevOps это как раз не про написание инструментов, а про продвижение правильной культуры в организации и про пробитие определённых в том числе административных барьеров. Много раз видел когда куча технически грамотных людей пилят какую-то чепуху даже не потому что продукт такой, а потому что нет воли, желания и т.п. менять культуру в организации и они очевидно хотят просто тихо сидеть на своём месте и спокойно получать зарплату не развиваясь. Имхо DevOps должен быть двигателем и спокойная жизнь это не про DevOps. Поэтому многие люди, которые пришли в DevOps из системного администрирования, но работаю просто как продвинутые системные администраторы, которые умеют немного программировать, на самом деле не являются DevOps'ами ещё и потому, что работают в разных с культурой DevOps, как её понимаю я, парадигмах.
В этом конкретном случае организация, к сожалению, никак не готова согласиться на запрет этих ручных изменений.
Crossplane отличный инструмент, знаю его, но я имел ввиду (возможно выразился не совсем точно) именно про работающие с Terraform инструменты, которые можно было бы использовать с этой задачей.
На самом питон тут вообще не нужен, т.к. aws cli ставит свой, а несколько остальных утилит просто не используются.
Но в рамках уже написанного можно использовать установленное совершенно без проблем.
Вообще люблю я эти shyaml, jq, yq, envsubst и т.д. Места много не занимают, а автоматизации вполне хорошо помогают, удобно иметь их в случае чего.
del
А что используется у вас?
Чтобы покопаться в слоях, мало ли не знаете и вам интересно, есть прикольная штука (таких много есть, но эта нравится): github.com/wagoodman/dive
Так-то у Terraform / Terragrunt и свои уже собранные контейнеры есть и собирать свой в целом смысла почти нет.
По-поводу python3-dev и build-essential принимаю, но лень мне было из-за несчастного aws cli делать multistage, к тому же у меня работает несколько другой контейнер. Плюс вам поставить пока не могу из-за недостатка кармы.
И всё же ссылка по использованию ADD, которую я привёл даже в названии имеет dockerfile best practices, вы можете делать как угодно. Лично мне больше нравится именно curl или wget'ом делать такое, пускай это ещё + утилита. А так конечно нужно билдить отдельно, потом перекладывать в from scratch и т.п.
Я чуть было не положил в cloud-init такое:
apt updateapt install -y cargo
cargo install prometheus_wireguard_exporter
Потом подумал, что народ попытаясь это развернуть заждётся пока Rust это соберёт и всё-таки выложил бинарник. Точнее я раскатал это на t2.medium, заждался, сбилдил у себя на i9 и выложил бинарь :)
Поэтому и написал про холивар :)
Мне лично их документация тоже не нравится, как-то лично на мой вкус сложно всё ищется, если искать не натравливая гугл на неё и stackoverflow, а прямо в ней.
Тут очень много что можно исправить, а цель статьи в том, чтобы показать, что можно сесть и автоматизировать что-то за пару часов. Потом, естественно, рефакторить.
Но кстати,
docs.docker.com/develop/develop-images/dockerfile_best-practices/#add-or-copy
Because image size matters, using ADD to fetch packages from remote URLs is strongly discouraged; you should use curl or wget instead. That way you can delete the files you no longer need after they’ve been extracted and you don’t have to add another layer in your image. For example, you should avoid doing things like:
ADD https://example.com/big.tar.xz /usr/src/things/RUN tar -xJf /usr/src/things/big.tar.xz -C /usr/src/things
RUN make -C /usr/src/things all
And instead, do something like:
RUN mkdir -p /usr/src/things \&& curl -SL https://example.com/big.tar.xz \
| tar -xJC /usr/src/things \
&& make -C /usr/src/things all
For other items (files, directories) that do not require ADD’s tar auto-extraction capability, you should always use COPY
Let the holy war begin :)
Боязнь облаков свойственна больше Российским проектам, т.к. видимо, здесь политические риски несколько выше.
Но serverless на мой взгляд, это всё же про облака, поэтому если у вашего проекта есть политические риски, то вероятно лучше использовать другую технологию, благо на serverless свет клином не сошёлся.