1. Куча / Говнокод #27242

    0

    1. 1
    Объясните, зачем нужен docker-compose

    Есть же Dockerfile, туда можно поставить всё, что нужно сразу, а не плодить кучу контейнеров, которые нужно связать

    Запостил: Крендель, 09 Февраля 2021

    Комментарии (45) RSS

    • Ого какой олдфаг
      Ответить
    • Еще через полгода обнаружится парадигма "один контейнер - один процесс"*

      * что тоже не совсем верно. Один контейнер - один сервис, если ему надо плодить дочерние процессы, то в общем-то никаких проблем с этим нет.
      Ответить
    • Docker-compose нужен чтобы наплодить кучу контейнеров. Если тебе нужен всего один контейнер, то и компоуз тебе нафиг не нужен. Только тогда у тебя вместо нескольких маленьких точек отказа появится одна большая.
      Ответить
      • > нескольких маленьких точек отказа

        Как что-то хорошее. Один хер большая часть функционала ляжет если каждого сервиса по одной штуке.
        Ответить
        • Меньше времени уйдёт на поиск неисправности.
          Ответить
          • Да я бы не сказал... Обновлять и перезапускать по частям удобнее, да.
            Ответить
    • Просто докер так спроектирован, что проще описать и поднять десяток мелких контейнеров, чем ебаться с одним большим франкенштейном.
      Ответить
      • обоснуйте!!!!!
        Ответить
        • Удобные иструменты для работы с кучей контейнеров завезли, а инструменты для упихивания кучи говна в один -- нет.

          Получается недовиртуалка с недопрыщами.
          Ответить
          • 1) чем всякие апт инсталлы в виртуалке отличаются от апт инсталлов при сборке образа?
            2) не завезли - я хз в каком вы там году https://www.packer.io/docs/builders/docker
            Ответить
            • Основная прыщепроблема fat образов (и виртуалок и физических машин тоже, само собой) в том, что ты можешь ставить только те версии софта, которые предусмотрел мейнтейнер дистриба. Если ты хочешь придержать что-то более старое или накатить что-то более современное -- готовься к ёбле.

              С мелкими образами этой проблемы нет, ты можешь обновить или заморозить любой из них.
              Ответить
              • А как это меняет ситуацию с убунтой в контейнере или в вм?
                Ответить
                • А никак, как было хуёво так и осталось. Смысл пердолиться с докером, если ты не хочешь изолировать проги друг от друга? Виртуалка удобней получается, имхо.
                  Ответить
                  • начали с "докер так спроектирован", кончили "удобней"

                    вообще смотря что надо. докер легковесней, из виртуалки сложней выпругнуть и никакой ебли с зашаренными ресурсами (хоть dentries вспомнить)
                    Ответить
                    • ну и ещё докер небезопасный (очень аккуратно нужно чекать зависимости и фиксировать версии), но типа смузихлёбский.
                      Ответить
        • надокерхаб
          FROM суперговно:1.0

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

          А если тебе надо дохуя чего — то у тебя будет раздутый докерфайл форкнутый от непонятно чего, чего-нибудь базового куда всё доставлять будешь руками.

          Вывод: четыре контейнера с докерфайлами в одну строчку лучше, чем один с докерфайлом в километр (зависимости, хуё-моё, не дай бог make прямо там же)

          Если нужно зеркалить все зависимости для продакшена, то можно и поебаться, но имхо даже если всё вручную собирать, всё равно лучше побить на контейнеры, /green модульность — это всегда хорошо.
          Ответить
          • > Если нужно зеркалить все зависимости для продакшена

            Увы, но иначе никак. Что ты там с хаба качаешь - хуй знает, выдал ты dnsmasq cap net admin, а там жук усатый весь твой нетворк слушает, таракан-оборотень.

            Впрочем, с виртуалками ровно та же история.
            Ответить
            • Но в этом смысле может даже оказаться, что собрать один раз образ и запушить себе в локальный хаб (а докер даёт такую возможность), будет опять же надёжнее, чем с виртуалкой. И ебаться с безопасностью только когда понадобилось сделать ещё один build, то есть при обновлении приложения, а не постоянно.
              Ответить
              • Да все равно надо постоянно пересобирать из-за секьюрити патчей

                Короче, говно, блядь, нельзя без ебли короче, мартин алексеевич, заводим говнодевопс.ру
                Ответить
    • Объясните лучше вот что: http://cpp.sh/6txwm

      Почему при второй конкатенации программа не падает?
      Я же из скоупа main передал объект в другой скоуп, и переместил его, почему уник_указатель sn продолжает держать объект, ведь я его обратно не вернул? По идее же move конструктор должен очистить его.
      Ответить
      • Точнее, должна была вызваться во второй раз make_unique.
        И вывелось бы:
        1
        2
        Ответить
      • Это с собеседования задачка, да?
        Ответить
        • Нет, просто упрощенный пример реальной задачи.
          Ответить
      • Дык ты не мувал ничего, вот оно и не мувнулось.

        Не забывай, что std::move() нихуя не делает. Это просто каст такой.
        Ответить
        • Ну да std::move просто в rvalue ссылку преобразует.
          Ну так у меня что получается, два уникальных указателя на один объект в какой то промежуток времени ссылаются?
          Ответить
          • Почему два то? Один, который sn в main'е. А sp в concat это rvalue ссылка на него же.

            З.Ы. Не пойму зачем тебе тут rvalue ссылка, обычная точно так же отработала бы.
            Ответить
            • Ну и как тогда определить, когда по && вызывается move конструктор, а когда это просто ссылка?
              Наверное, когда сами вызываем конструктор или оператор призваивания?
              Ответить
              • У меня в Cи по && никаких конструкторов не вызывается, именно поэтому я за Си.
                Ответить
              • Никак. Вызывающему коду должно быть похуй на состояние объекта после такого вызова. Объект окажется в каком-то состоянии, пригодном для разрушения. К примеру, в том же самом, что и до вызова, лол.

                Если вызывающему коду не похуй и он продолжает дёргать методы -- код написан криво.
                std::string s;
                test(std::move(s));
                // теперь s находится в неопределённом состоянии, пригодном для разрушения
                // больше юзать его нельзя
                Ответить
                • Rust какой-то!
                  Ответить
                  • Ну да, только питушня по рукам бьёт, если продолжаешь юзать. А крестам как всегда похуй.
                    Ответить
                • З.Ы. Я не совсем правильно написал:

                  - неопределённом состоянии, пригодном для разрушения
                  + неопределённом но валидном состоянии

                  Т.е. таки можно туда что-то потом присвоить или позвать reset. Но на то, что там лежит до этого момента, корректной проге должно быть похуй.
                  Ответить
                • То ли дело Rust:
                  https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html

                  > In languages with pointers, it’s easy to erroneously create a dangling pointer, a pointer that references a location in memory that may have been given to someone else, by freeing some memory while preserving a pointer to that memory. In Rust, by contrast, the compiler guarantees that references will never be dangling references: if you have a reference to some data, the compiler will ensure that the data will not go out of scope before the reference to the data does.
                  Ответить
                  • Ну в этом случае нету ни утечек ни крашей. Просто функция не воспользовалась своим правом на мув. Её право.
                    Ответить
                    • У меня в Си у функций нет никаких "прав на мув", я просто явно аллоцирую/освобождаю память и переприсваиваю указатели. А то вот понапридумывали какие-то права на мув, совсем уже охуели, может там функции еще забастовку или митинг могут устроить?
                      Ответить
                      • > я просто явно аллоцирую/освобождаю память и переприсваиваю указатели
                        - внутри каждой функции?
                        Ответить
                      • Ой да ладно. Один фиг в сишке приходится как-то пояснять читателю где функция принимает аргумент "на посмотреть", а где "владение передали".

                        Тут попытались это немного формализовать.
                        Ответить
                      • я вообще не понимаю, нахуй все эти типы? зачем эта сложность? просто берешь, выделяешь восемь байт на стеке и опкоды вызываешь, понапридумывали, блядь
                        Ответить
                        • Так-то оно так, но на самом-то деле опкоды тоже хуйня. Надо чтоб переконфигурируемая ПЛИС, и чтоб бинарники были байтстримом для FPGA. Например, захотел ты запустить условный Word - прошиваешь часть своей FPGA этим вордом и используешь. А то вот современные процессоры с фиксированным набором всяких там говноинструкций это хуйня какая-то
                          Ответить
                          • > ПЛИС

                            Там же куча оверхеда и фиксированный набор ячеек... Остаётся ждать пока появится дешёвая технология для печати ASIC'ов.
                            Ответить
                            • Да, в компьютере держать мини-заводик по изготовлению ASIC-ов, и при запуске какой-то новой проги чтоб он собирался этим заводиком и вставлялся в слот на материнке. А так можно иметь набор готовых асиков и просто переподключать их особым встроенным механизмом, как картриджи в приставках когда-то
                              Ответить
                              • > при запуске

                                При установке же. И потом можно реюзать пока не выбросишь.
                                Ответить
                      • FLM
                        Ответить
    • Иметь сервисы в отдельных контейнерах и систему оркестрации для них позволяет сделать несколько хуйнь, которые нужны редко и не всем, ну например несколько инстансов приложения или одного сервиса внутри приложения, и распределение между ними. Живое обновление приложение без даунтайма (подняли рядом новый инстанс, только потом уронили старый). Кроме того, а схуяли это всё в один докерфайл пихать? А может мне нужно разное окружение для сервисов. Например одному элементу стека нужна либа другой версии. Сделать другой контейнер проще, чем запихивать еблю с разруливанием всего этого в докерфайл. Или, вдруг ты решил, что теперь у тебя база не на одной машине с приложением, а лежит в датацентре в цюрихе. Твои действия, если у тебя до этого она лежала в одном докерфайле с аппликейшеном? А если была отдельным контейнером — то переписать один урл в конфиге.
      Ответить

    Добавить комментарий