Комментарии 12
А что насчет защиты от публичного доступа? В текущей конфигурации любой желающий может открыть ссылку типа https://web-pr-311.s3-website.ap-northeast-2.amazonaws.com и посмотреть что у вас там.
Советую посмотреть на bucket policies и настроить их себе.
И как всегда, где-то к середине статьи весь код плавно превращается в баш. "Как мы написали наш пайплайн на баше, подход к снаряду №100500"
Каждый раз, как я вижу пайплайн на баше, мне хочется собрать пайплайн на джаве )). Я прямо убеждён, что получится лучше
У меня есть только зараждающееся ощущение о великом разделе между языками программирования и системами описания сайд-эффектов. (https://amarao.dreamwidth.org/9493.html) Сама мысль ещё сырая и я её думаю, но в общих чертах: языки программирования работают в рамках полного знания о системе и высокой надёжности (если вы написали a=1, то вы точно знаете, что у вас есть переменная a и её значение 1).
При этом сайд-эффекты (реальный мир) не подчиняются этой модели, очень сложны и живут своей жизнью. Вероятнее всего, это ведёт куда-то в кибернетику…
Ладно, в контексте CI: происходящее в CI — это всегда (за вычетом юнит-тестов) ядрёный сплав глубоких концепций языка программирования (который предполагает строгое следование модели памяти, абстракциям и т.д.) и сайд-эффектов окружающего мира (что у вас там в зависимостях было? foobar=1.3.4? Ой, а у нас же нет прав записи в каталог foobar, и по сети нам ответили 500, а обращение к серверу №2 — timed out).
И попытка описывать окружающий мир на языке программирования с полным знанием (java, rust, python, C++, haskel, ocaml, etc) приводит к тому, что вы либо халтурите (не имеете полного знания), либо срезаете углы (и тогда используете неподходящий язык, см ниже), либо изобретаете окрестратор с ответами на большинство неожиданных воздействий.
Существует другая модель отношения к реальности — экзестенцианализм, который принимает окружающий мир как хаотичную систему и пытается сделать в ней наименьшее количество изменений (поскольку любое изменение может привести не к тому, что хочется). Это путь баша/ансибла и т.д.
И вот баш тут плох уже как язык, потому что на нём сложные вещи опасно писать.
Согласен с тем, что сложные куски логики делать на баше лучше не стоит. Я на такие грабли уже наступал раньше.
но тут достаточно простая логика + львиная доля работы делается под капотом aws-cli
И вот баш тут плох уже как язык, потому что на нём сложные вещи опасно писать.
Я бы сказал сложно, долго и отсутствует инструментарий для разработки.
Наверное, с точки зрения человека, который хорошо владеет башем — баш это просто супер. По крайней мере я такую точку зрения встречаю регулярно.
Но мне, всё что не просто склеивание утилит в пайплайн, приходится гуглить. Но даже если бы я не гуглил, я всё не могу написать юнит тесты на логику, а это приводит меня в перманентно нервозное состояние. Логика это, кстати всё, что не склейка. if, test [, || вот это всё. Я уже дошёл до такого состояния, что меня триггерит чуть ли не проверка любого условия.
Джавой я могу так же склеить утилиты в пайплайн, это несложно, плюс я могу описать логику, плюс я могу написать юнит тесты, плюс я могу сделать всё, что угодно, не зависая часами в гугле.
У скриптов есть преимущество, что можно поправить скрипт "на месте", но во-первых с джавой сейчас так тоже можно, а во вторых я годами занимаюсь тем, что пишу код, любое изменение в котором тестируется, проходит через пайплайн и запускается где надо и когда надо. Любой разработчик сейчас это умеет, проблем нет.
Как я вижу, чтобы заменить баш, на языках общего назначения пилят всякие DSL типа ansible и иже с ней. Но если принять тот факт, что назначение шелл скриптов — склеивать утилиты в пайплайн, то для того, чтобы заменить баш на джаву, достаточно просто сделать библиотеку, которая немного упростит комбинирование сторонних утилит. И всё. Непонятно почему до сих пор никто не занялся.
Я ни разу не видел пайплайнового кода на джаве, но в целом понимаю ценность: однородность среды разработки. Джавист пишет в своем spring boot проекте код доставки на той же джаве.
Я, наоборот, слышу от людей, которые десятилетями пишут на баше, что на баше очень просто писать и очень сложно писать правильно и хорошо (в сравнении с другими языками). Обработка ошибок в баше неочевдная, дефолты странные. Последствия — вместо ошибки баш просто продолжает выполняться, делая что-то.
На самом деле, достаточно почитать как правильно сравнивать строки на равенство в баше, чтобы понять, что это такой оголосок Си с Сишной же ментальностью.
https://stackoverflow.com/questions/2237080/how-to-compare-strings-in-bash
В то же самое время с Явой (на самом деле любым контролирующим языком программирования) у вас буде проблема с тем, что вы будете иметь слишком строгие ожидания от реальности. Ваша программа будет либо иметь много кода (есть права? место есть?), либо будет выдавать ошибки там, где их можно было бы избежать. Ещё хуже, если ваша программа вместо минимально необходимого воздействия будет делать что-то больше (и с этим придётся считаться).
… и вы очень сильно недооцениваете сложность пайпов и запуска процессов.
Сам себе DevOps: строим cloud-only CI для веб приложения