👀 Раз такая тема, кто какие нормальные способы деплоя использует?

Без докеров и прочей мутоты.

С докерами это как раз нормальные. 😁

А можно кратко, чем оно нормальней чем традиционные методы? Может действительно нужно научится их готовить. Но надо понять плюсы 🤷‍♂️

Будешь в ручную на 15 серверов накатывать все и при малейших изменениях повторять все с нуля? Хотя даже в рамках одного сервера это удобнее. А еще контейнеризация помогает решать некоторые проблемы с безопасностью.

Ну да, не уточнил. Среднестатистический ординарный кейс: одно свифтовое серверное приложение - один сервер. Я ничего не утверждаю, просто интересно кто как делает. До докеров жизнь существовала на сервере, и очень было все не плохо. Ни свифта, ни даже пуфона не было. «Деплой» делали через ssh (sftp) 🤷‍♂️

помойму это всё-таки вопрос вкусовщины…всегда можно пойти и руками всё задеплоить, можно написать какие-то минимальные скрипты, а можно всё пропустить через докер, но докер (если вдруг я не прав - я не прав, не кидайтесь в меня тапками) - больше про виртуализацию в первую очередь. Он может быть бесполезен в простых кейсах, но когда начинаются нюансы - спасает. Мой личный кейс - требовался микровнутренний сервис, помимо этого - требовалось взаимодействовать с ROS, параллельно нужно было дебажить iOS приложение…в итоге получаем 2 варианта зоопарка, где: 1. Ты пианист на нескольких машинах, потому что iOS - на маке, “””“бэк”””” (в целой куче кавычек) + ROS на убунту (и тут нет опции запустить на mac, ROS только в теории существует на маке, но преимущественно - на Ubuntu) 2. Ты пианист девопса в виде докера, где можно всё на одной машине отдебажить вот и получается, иногда удобнее на разных машинах, иногда на одной, иногда удобнее руками задеплоить

Стикер

Да, таков современный взгляд на вещи — аксиома, не требующая доказательств. И как для всякой аксиомы, применение докера в вырожденных случаях (типа, единственное приложение на единственном сервере) всерьез обосновать заслуживающими внимания аргументами не может никто. :)

Стикер

Стикер

Стикер

Стикер

Проблема в зависимостях, хост систему надо обновлять, ну чтобы не было проблем с безопасностью как минимум. И когда у тебя в системе стоит куча зависимостей приложения, то это плохо. Докер это все добро изолирует и дает наружу только один порт. Пакетов на хост системе минимум и обновление ничего не сломает. Да у самого докера есть проблемы, но они известны и есть какие-то решения.

Стикер

Стикер

Никогда не наступали на проблему версий ssl?

Даже не слышал о такой

Стикер

А! Вы наверное имеете в виду, что если на сервере стопиццот приложений, то зависимости одних конфликтуют с другими. Мне, вероятно, следовало пояснить, что "колхозные" сервера я не имел в виду. Один сервер — одно приложение.

Дело не в оркестрации, а в создании независимого окружения, можете lxc контейнеры использовать или образы виртуальных машин. А управлять этим всем всем уже дело 10-ое, в любом случай ssh почти все тулзы поддерживают.

Проблема в утилизации ресурсов.

Придется еще немножко пояснить — я не против докера или контейнеризации. Там, где это объективно необходимо, оправданно, и известны все плюсы и минусы. Это в любом случае предполагает некоторый масштаб и определенную квалификацию. Но я против использования контейнеризации на одной-единственной 10-долларовой VPSке, на которой в разных контейнерах запускается и само приложение, и постгрес, и еще что-нибудь, при этом запускается всё с полпинка и через полчаса у нас уже сайт работает. И вот эти "через полчаса уже всё работает" — это часто единственная причина использования докера. Когда так поступают для ознакомления с тем же вапором, быстренько запустить, посмотреть, потрогать — это ок. Когда в том же виде оставляют для работы в проде — ну извините. А это сплошь и рядом.

Сейчас принять так, один контейнер одно приложение. Оркестратор пытается максимально утилизировать ресурсы кластера на счет передвижение контейнеров по нодам.

См. выше.

Стикер

Ну тут дело в том что расширить докер до докер сварм дело 10 мин, а в ручном режиме надо будет поупражняться. Плюс в ручном режиме скорее всего сервера будут отличаться в настройке или надо вести доку с конфигом и ее обновлять постоянно. Так же есть вопросы повторяемости. Нету в линуксе аналога лок файла для системных зависимостей. И того рано или поздно будут сервера снежинки, каждый по своему уникальный и неповторимый в настройке.

Вот мы с вами разговарием, и при этом ясно ощущается, что у каждого в голове некое представление о том, о чем он говорит, остающееся за кадром. :) Всё же давайте вернемся к конфигурации, с которой началось — один сервер, одно приложение, нужен ли докер.

Для того чтобы ответить на этот вопрос однозначно надо ответить на кучу других вопросов. Если приложение не монолит, а набор сервисов, монолитов или еще чего-то такого, то да нужен. В общем будет ли двигаться приложение в кластер, если да то тоже надо. Дальше вопрос инфраструктуры как кода, если надо описание инфры в виде кода, то да докерфайл лучше чем ридми в кучей команд. Дальше безопасность, докер образ так или иначе можно подписать и проверить на валидность. С сорцами в папке это надо делать вручную. Есть еще организационные вопросы, кто админ сервера, кто отвечает за деплой, и т.д. Для лабы докер самое то например, развернуть убить окружение делается в одну команду. Для пета докер почти всегда будет избыточен.

Стикер

Стикер

Стикер

на деплой машине нету сорцов? 🙂 ну ок

Если под деплой-машиной вы подразумеваете таргет-машину, на которой приложение работает, то сорцов там нет. На сборочной машине они, естественно, есть.

а все темплейты, ассеты они тоже в бинарнике?

Стикер

Стикер

тоесть если будет взлом и положат какашку в js - то про это никак не узнаем 🙂

да я такие вопросы и без докера постоянно встречаю, только в других чатах. ну если человек не понимает как работает сеть, то одинаково, приложение в докере или нет. и логи линукса такие люди не найдут так же как и логи докера.

Вот жеж блин. Пароли скрыл, ключи скрыл, всё скрыл, но JS не скрыл — и тут же прилетело. А чо сразу я-то? А они? А я? А у них вон всё в .env файлах и ничего. А у меня js открыт и сразу всё плохо. Но мысль интересная. Как предложите поступить с JS? Положить где-то отдельно? Но то место, куда они будут положены, тоже можно взломать.

если человек вчера увидел линукс то тоже результат будет такой же, это вопрос инструкции по которой что-то делает такой человек и ошибок в этой инструкции

Скорее всего, они осмотрятся и полезут в systemd.service смотреть на предмет переменных среды, увидят там IP постгрес базы, стукнутся в нее — и вот тут мы про них и узнаем, потому что по тому IP вовсе не постгрес живет. :)

С голым линуксом проще всё же. Ровно в 2 раза чисто арифметически.

ну тут просто, образ подписываем и проверяем подпись. а пароли, да и всякие секреты надо хранить или в vault или в соответствующих местах в облаке.

Стикер

не проше, линуксы разные, убунту слегка отличаеться от дебиана, а от сусе отличий еще больше, а есть еще генту например

Пароль от vault/облака где хранить? Это же извечный вопрос: — Надо контролировать, нужны контролеры — Ок, а кто будет контролировать контролеров? Эта цепочка контроля — бесконечна, и в конце ее — пароль, который должен быть доступен приложению, чтобы оно имело доступ к другим паролям.

Ну т.е. вчерашний iOS'ер поставил в качестве сервака не убунту или хотя бы дебиан, а генту. :) Вы сами-то верите в реальность подобной ситуации? :)

https://github.com/hashicorp/vault - вот как пример и стандарт дефакто даже в облаках,

Спасибо, поразбираюсь

Funtoo в чем проблема? opensuse тоже ставиться просто

ну или у хостера выбрал темплейт, у генту есть куча плюсов, почему бы и нет?

Очевидно, что ваш бэкграунд столь обширен, что на уровень "простых смертных" вам опуститься довольно сложно. Это не проблема. Это просто в голову не придет никому, потому что везде убунта, 90% инструкций в инете про убунту, готовые аппы, предоставляемые хостерами, тоже убунту-based.

и это до первой поломки убунту при обновлении 🙂

У вас не получается поставить себя на место новичка, ну никак. :)

Лучше скажите, цитирую: Vault can generate secrets on-demand for some systems, such as AWS or SQL databases. For example, when an application needs to access an S3 bucket, it asks Vault for credentials, and Vault will generate an AWS keypair with valid permissions on demand. Вот когда приложение asks Vault for credentials, оно как себя авторизует в Vault?

Хочется лекций на эту тему, и учебник, с подписью автора! ☺️

На хабре много интересного по теме

Если я правильно понял вопрос, то вот дока https://developer.hashicorp.com/vault/docs/auth/approle?product_intent=vault

Стикер

Как раз наоборот, для простых смертных докер будет самым понятным и логичным, а вот с ростом уровня уже ясно слабые и сильные стороны и уже можно выбирать что и где использовать.

Пока не могу продраться сквозь богатство описываемых возможностей и получить из доки ответ на простой вопрос — вот на VPS есть приложение, оно обращается за нужным ключом/секретом/токеном в Vault. Как оно себя авторизует при запросе? Пока что я вижу, что оно может принести пароль, токен и т.д. Ну т.е. они должны быть доступны приложению. Проводя аналогию — все мои пароли и проч. хранятся в 1Password. Для доступа к ним нужен мастер-пароль. Если я — это не человек, а приложение, то этот мастер-пароль должен где-то храниться. Где? На диске? Тогда он доступен взломщикам. В другом 1Password? :) Где? Пока что не понимаю.

Стикер

В целом, если Вы - человек, то мастер пароль тоже где-то хранится. Назовем просто "в голове". Так вот, путем нехитрых манипуляций со спичками или утюга, пароль можно тоже "узнать"))

Или так, сути не меняет.

Меня сейчас интересует кейс, когда я не человек. :)

Я же скинул доку, у вашей апки есть айди, по нему получили токен доступа и получили нужные данные из ваулта. С правами доступа и т.д. Одна апка получит пароль к бд, другая нет.

Ну ладно, айди так айди ¯\_(ツ)_/¯

В облаках используют айди контейнера, или как в доке machine id, можно апку на части нарезать и каждой части дать свой айди.

Я ждал этого ответа 🤓🤝

Многие покупают одежду в магазине. Зачем — непонятно. Шутка. На самом деле понятно, и это не раз озвучивалось: чтобы сэкономить время, не заниматься созданием лекала, шитьем, проверкой качества и т.д. Один магаз — одежда на все случаи жизни. Клево же. Особенно, когда не держал иголку в руках. Но одежда — это не только материал и напяливание на себя шмоток. Это много чего. И если копнуть глубже, то окажется, что у этих многих есть еще куча слабых мест. Начиная (и не заканчивая) не совпадением размера, бесючей этикетки в самых нежных местах. По факту покупка одежды сокращает процентов 10% необходимой работы, которую нужно выполнить перед тем как выйти в люди. Но посколько любители упрощений и фастфуд потребления… (дальше лень печатать, можно такой аргумент привести?)

Стикер

Стикер