Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 13
Спасибо.
И вот что что, а по terragrunt'y было бы интересно почитать детальнее — может быть даже отдельную статью ( как/куда/зачем/структура и тд). Сколько раз смотрел их документацию все напоминает историю про урок рисования в школе — типа рисуем кружочек и еще один, а потом рисуем сову. Нигде толкового описания как и что не нашел.
И вот что что, а по terragrunt'y было бы интересно почитать детальнее — может быть даже отдельную статью ( как/куда/зачем/структура и тд). Сколько раз смотрел их документацию все напоминает историю про урок рисования в школе — типа рисуем кружочек и еще один, а потом рисуем сову. Нигде толкового описания как и что не нашел.
Уух, сколько слоев то, в продакшене за такое по рукам бьют ))) Вместо RUN wget… можно использовать ADD ...
Я потому и написал «За код не ругайте, написал за несколько часов и решил поделиться.»
Тут очень много что можно исправить, а цель статьи в том, чтобы показать, что можно сесть и автоматизировать что-то за пару часов. Потом, естественно, рефакторить.
Но кстати,
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:
And instead, do something like:
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 :)
Тут очень много что можно исправить, а цель статьи в том, чтобы показать, что можно сесть и автоматизировать что-то за пару часов. Потом, естественно, рефакторить.
Но кстати,
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 allAnd 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 allFor other items (files, directories) that do not require ADD’s tar auto-extraction capability, you should always use COPY
Let the holy war begin :)
Но кстати,ADD же может сразу распаковывать, tar.gz/zip так точно. Единственное — ADD не поддерживает аутентификацию, но это не ваш случай
docs.docker.com/develop/develop-images/dockerfile_best-practices/#add-or-copy
python3-dev \что это делает в рабочем образе? Прочитайте что такое multistage builds
…
build-essential \
Ещё раз перечитайте первую строку моего предыдущего комментария и не набрасывайте, смысл статьи не показать все best practices, а с близкой к максимальной скорости реализовать автоматизацию.
И всё же ссылка по использованию ADD, которую я привёл даже в названии имеет dockerfile best practices, вы можете делать как угодно. Лично мне больше нравится именно curl или wget'ом делать такое, пускай это ещё + утилита. А так конечно нужно билдить отдельно, потом перекладывать в from scratch и т.п.
Я чуть было не положил в cloud-init такое:
Потом подумал, что народ попытаясь это развернуть заждётся пока Rust это соберёт и всё-таки выложил бинарник. Точнее я раскатал это на t2.medium, заждался, сбилдил у себя на i9 и выложил бинарь :)
Поэтому и написал про холивар :)
И всё же ссылка по использованию 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 и выложил бинарь :)
Поэтому и написал про холивар :)
Ещё раз перечитайте первую строку моего предыдущего комментария и не набрасывайте, смысл статьи не показать все best practices, а с близкой к максимальной скорости реализовать автоматизацию.статья для новичков, а у вас такие ляпы, но дело ваше
Когда даёте советы убедитесь, что они сами соответствуют best practices :)
Чтобы покопаться в слоях, мало ли не знаете и вам интересно, есть прикольная штука (таких много есть, но эта нравится): github.com/wagoodman/dive
Так-то у Terraform / Terragrunt и свои уже собранные контейнеры есть и собирать свой в целом смысла почти нет.
По-поводу python3-dev и build-essential принимаю, но лень мне было из-за несчастного aws cli делать multistage, к тому же у меня работает несколько другой контейнер. Плюс вам поставить пока не могу из-за недостатка кармы.
Чтобы покопаться в слоях, мало ли не знаете и вам интересно, есть прикольная штука (таких много есть, но эта нравится): github.com/wagoodman/dive
Так-то у Terraform / Terragrunt и свои уже собранные контейнеры есть и собирать свой в целом смысла почти нет.
По-поводу python3-dev и build-essential принимаю, но лень мне было из-за несчастного aws cli делать multistage, к тому же у меня работает несколько другой контейнер. Плюс вам поставить пока не могу из-за недостатка кармы.
Чтобы покопаться в слоях, мало ли не знаете и вам интересно, есть прикольная штука (таких много есть, но эта нравится): github.com/wagoodman/diveда много чего есть, у нас в CI встроен анализатор docker образов
ADD example.com/big.tar.xz /usr/src/things/оказывается они редиски убрали эту фичу у ADD в 17.06, а было очень удобно
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:
Эту штуку, которая https://github.com/wagoodman/dive как раз тоже встраивают в ci и можно заваливать сборку, если определённые параметры вроде lowestEfficiency, highestWastedBytes или highestUserWastedPercent ниже, чем вам нужно и можно их естественно задавать https://github.com/wagoodman/dive#ci-integration
А что используется у вас?
А что используется у вас?
RUN set -x && \кстати очень плохая практика, так и сломать что то можно в системе. Я бы не советовал так делать. Как минимум в ansible нахлебался вдоволь
ln -sf /usr/bin/python3 /usr/bin/python && ln -sf /usr/bin/pip3 /usr/bin/pip
На самом питон тут вообще не нужен, т.к. aws cli ставит свой, а несколько остальных утилит просто не используются.
Но в рамках уже написанного можно использовать установленное совершенно без проблем.
Вообще люблю я эти shyaml, jq, yq, envsubst и т.д. Места много не занимают, а автоматизации вполне хорошо помогают, удобно иметь их в случае чего.
del
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
DevOps: автоматизация инфраструктуры на примере Terraform, docker, bash, prometheus exporters, Gitlab и WireGuard