> хотели попилить монолит на отдельные сервисы (но не микросервисы, а просто сервисы)
О, Автор! В Вашем случае, какая была разница между микро- и просто сервисом?
Я понимаю, что это холиворная тема и понятия растяжимые, но в данный момент сам замешан в распиливании монолита, и любопытно, где другие люди проводят границу?
Человек может не знать ни о каких докерах, кубернетисах, итп.
У кого-то другая система представлений.
Может кто-то просто не хочет знать ничего, кроме явы?
погрести Докер под плотным слоем абстракций, чтобы работа с ним осуществлялась аналогично класслоадерам в джаве или бинам в спринге, через прозрачный доступ по Java API и только через него
Вот это как раз оно. Грести докер под плотным слоем абстракций. Натянуть сову на глобус, чтобы было все через ява АПИ.
должен же разработчик на своем компьютере запустить сервис, с которым ты интегрируешься прямо сейчас и погонять немного тестов?
Конечно, он может. Те разработчики, которые хотят «немного погонять» в нашем случае предпочитают запускать spring boot у себя без докера на голом железе (им так привычнее и быстрее). Те разработчики, которые хотят локально выполнить интеграционный набор тестов а-ля Jenkins полностью — просто запускают mvn verify (который билдит и запускает все докеры с зависимостями локально) При этом в коде тестов — только логика тестов, вся конфигурация докеров — в настройках мавен докер плагина. И я настаиваю, что держать конфигурацию докеров снаружи тестового кода — лучше, чем засовывать её внутрь.
Да, тридцать два гига рамы на локальном компьютере, да — i7, SSD, и по несколько минут на запуск. Но связываться с «полномасштабной» инфраструктурой — это еще больнее!
«TestContainers — это Java-библиотека, которая поддерживает тесты JUnit и предоставляет легкие, временные экземпляры основных баз данных, веб-браузеров для Selenium или чего угодно еще, что можно запускать в Docker-контейнере».
Этот дисклеймер слегка сбивает с толку.
Выходит, что не «чего угодно ещё», а только того, что влезет на локальный компьютер.
В случае с selenium тестами — как правило речь идет о системном тестировании, где не обойдешься изолированным контекстом одного сервиса с базой данных, и где как раз и нужно поднимать эту самую полномасштабную инфраструктуру. Ну так вот kubernetes в этом случае спасает даже тех, у кого рабочий ноут с <32 Гб памяти. Опять же запустить kubernetes apply — как правило проще и быстрее, чем апгрейдить или покупать новые ноутбуки.
> Понравилась идея, есть сомнения?
да
> Будете ли вы пользоваться TestContainers?
нет
Из предыдущего и текущего опыта интеграционного и системного тестирование сервисов, для себя сделал вывод, что оркестрация докеров изнутри кода — идея ущербная по двум причинам.
1. Запускается только локально или на одной DOCKER_HOST ноде.
Идеальный сферический микросервис без зависимостей — будет ок.
Но реальные явишные сервисы, которые пришлось тестировать, жрут от полгига до 16 гиг памяти, имеют кучу зависимостей и на одну ноду просто не влазят. Тоже самое касается параллельного выполнения тестов. При попытке запустить дюжину selenium нод c chrome внутри — придется отдать гигов шесть, плюс собсвенно selenium grid — еще полтора — два гига, ну и собственно тестовым процессам памяти тоже бывает нужно по наблюдениям от половины до полутора гиг. Можно спорить о конкретных значениях и пытаться оптимизировать Xmx но на порядок величины — это не сильно влияет. Заурядная рабочая машина с 16 гигами памяти — не справится запустить этот тестовый сетап.
2. Второй контраргумент. Поптыка оркестрировать докеры из явишного кода — имхо, изобретание девопс велосипеда. Есть инструменты, которые делают лучше и больше.
Например
А. Вот этот плагин (были про него статьи на хабре даже) github.com/fabric8io/docker-maven-plugin — Тоже ограничен локальным хостом, но умеет не только запускать докеры для тестов и гасить после, но и собирать их, тегать, пушить в docker-registry на стадии mvn deploy, что удобно. Не подойдет ненавистникам XML конфигураций и мавена, однако проверен временем и работает удовлетворительно.
Б. kubernetes. Запросто жонглирует тяжелыми тестовыми сетапами, которые не поднимутся на локальной рабочей машине у разработчика, масштабирует компоненты по щелчку пальцев, про удобство конфигурации — и говорить нечего, это на два порядка лучше, чем конфигурить докеры в ява коде, к тому же любители YAML/JSON конфигов будут счастливы. Про тонны плюшек k8, которые идут впридачу к этому — тоже промолчу.
Вполне юзабельный плагин и спасибо за статью. Удалось прикрутить и использовать в рабочем проекте.
Из преимуществ — пересборка и запуск грозди контейнеров в нужном порядке до запуска интеграционных тестов, остановке и удаление всей этой кухни — после. Всё это — по одной команде mvn verify без внешних инструментов оркестрации и шелловских скриптов.
Из недостатков — разработчики плагина не всегда успевают догнать быстро развивающийся докер. Нужно потратить порядочно времени, чтобы сконфигурить плагин. Ну и сам факт использования лишнего звена в системе.
> А зачем лишняя нагрузка на проц SSH'ем? Секюрность? А чем FTP SSL/TLS не устраивает?
ssh удобен тем, что позволяет и выполнять команды, и переписывать файлы, FTP c SSL\TLS тоже нагружает проц
по поводу модификации lighttpd.conf — спасибо, взял на заметку, на досуге попробую
> Так у вас все-таки nginx или ngnix? Первый — это аксселератор статики для веб-сервера. Может и сам работать, но я не вижу в этом смысла. А второе — не знаю, что это.
ок. подловили на опечатке
> Чем nginx так кардинально отличается от бортового lighttpd?
критерием для выбора было потребление памяти
> WinSCP хорошая штука, но слово Win ее немного ограничивает виндой.
использование ssh не ограничено ни а) командной строкой, ни б) виндой
не нравится слово win — выберите любой другой гуй-клиент
>Функция MyCloud — обеспечить доступ к хранилищу без пробросов портов на роутере
соглашусь — это можно считать преимуществом
это также можно считать недостатком — вы коннектитесь к чужому серверу, чтобы получить доступ к своим данным
> Вы через веб расшариваете диск? А чем это отличается от встроенного WebFiles?
не только расшариваю диск, но и хостю галерею
> Хотите перенаправить корень веба с /var/www/web в другой каталог
не хочу
> подправьте соответствующим образом /etc/lighttpd/lighttpd.conf
смысла нет, этот файл перетирается при перезагрузке
> В общем все ваши вопросы, похоже, от не знания матчасти
вопросы были не мои, а ваши
> А что общего у MyCloud и ngnix&sshd? У них абсолютно разные задачи.
общего у них:
1. раздавать файлы с хранилища в интернет
2. заливать файлы на хранилище из интернета
> fun_plug безусловно чудная штука, но у него есть большущий минус — command line only
установленный ngnix «используется» удаленным пользователем через браузер а не через command line
установленный sshd обслуживает также WinSCP — вполне гуёвое приложение
туда же можно записать trаnsmission и массу другого софта
лень топтать клаву — наслаждайтесь мышкотыкательством на здоровье
параноику очевидны преимущества своего веб-сервера перед длинковским облаком
а для обывателей — ну пусть хотя бы знают, что есть альтернативы коробочному софту
использую DNS-325 в течении полугода
после того, как посмотрел на расход памяти и скорость передачи данных, отказался от MyCloud в пользу поднятых на нём же ngnix и sshd
была очень годная статья на хабре про эту железяку habrahabr.ru/post/155557/
изучение языка — это не только принятие к сведению абстрактных концепций, но и применение конкретных форм выражения этих концепций. У перла форма выражения концепций ООП отличается от других языков и это не способствует их освоению после перла.
Подробностей бы — где какие грабли лежат? Особенно любопытно Ansible vs Salt.
О, Автор! В Вашем случае, какая была разница между микро- и просто сервисом?
Я понимаю, что это холиворная тема и понятия растяжимые, но в данный момент сам замешан в распиливании монолита, и любопытно, где другие люди проводят границу?
жду статей про оркестрацию с помощью Scala и Haskel
Может кто-то просто не хочет знать ничего, кроме явы?
Вот это как раз оно. Грести докер под плотным слоем абстракций. Натянуть сову на глобус, чтобы было все через ява АПИ.
Конечно, он может. Те разработчики, которые хотят «немного погонять» в нашем случае предпочитают запускать spring boot у себя без докера на голом железе (им так привычнее и быстрее). Те разработчики, которые хотят локально выполнить интеграционный набор тестов а-ля Jenkins полностью — просто запускают mvn verify (который билдит и запускает все докеры с зависимостями локально) При этом в коде тестов — только логика тестов, вся конфигурация докеров — в настройках мавен докер плагина. И я настаиваю, что держать конфигурацию докеров снаружи тестового кода — лучше, чем засовывать её внутрь.
Этот дисклеймер слегка сбивает с толку.
Выходит, что не «чего угодно ещё», а только того, что влезет на локальный компьютер.
В случае с selenium тестами — как правило речь идет о системном тестировании, где не обойдешься изолированным контекстом одного сервиса с базой данных, и где как раз и нужно поднимать эту самую полномасштабную инфраструктуру. Ну так вот kubernetes в этом случае спасает даже тех, у кого рабочий ноут с <32 Гб памяти. Опять же запустить kubernetes apply — как правило проще и быстрее, чем апгрейдить или покупать новые ноутбуки.
да
> Будете ли вы пользоваться TestContainers?
нет
Из предыдущего и текущего опыта интеграционного и системного тестирование сервисов, для себя сделал вывод, что оркестрация докеров изнутри кода — идея ущербная по двум причинам.
1. Запускается только локально или на одной DOCKER_HOST ноде.
Идеальный сферический микросервис без зависимостей — будет ок.
Но реальные явишные сервисы, которые пришлось тестировать, жрут от полгига до 16 гиг памяти, имеют кучу зависимостей и на одну ноду просто не влазят. Тоже самое касается параллельного выполнения тестов. При попытке запустить дюжину selenium нод c chrome внутри — придется отдать гигов шесть, плюс собсвенно selenium grid — еще полтора — два гига, ну и собственно тестовым процессам памяти тоже бывает нужно по наблюдениям от половины до полутора гиг. Можно спорить о конкретных значениях и пытаться оптимизировать Xmx но на порядок величины — это не сильно влияет. Заурядная рабочая машина с 16 гигами памяти — не справится запустить этот тестовый сетап.
2. Второй контраргумент. Поптыка оркестрировать докеры из явишного кода — имхо, изобретание девопс велосипеда. Есть инструменты, которые делают лучше и больше.
Например
А. Вот этот плагин (были про него статьи на хабре даже) github.com/fabric8io/docker-maven-plugin — Тоже ограничен локальным хостом, но умеет не только запускать докеры для тестов и гасить после, но и собирать их, тегать, пушить в docker-registry на стадии mvn deploy, что удобно. Не подойдет ненавистникам XML конфигураций и мавена, однако проверен временем и работает удовлетворительно.
Б. kubernetes. Запросто жонглирует тяжелыми тестовыми сетапами, которые не поднимутся на локальной рабочей машине у разработчика, масштабирует компоненты по щелчку пальцев, про удобство конфигурации — и говорить нечего, это на два порядка лучше, чем конфигурить докеры в ява коде, к тому же любители YAML/JSON конфигов будут счастливы. Про тонны плюшек k8, которые идут впридачу к этому — тоже промолчу.
1. как при этом работают и выглядят скриншоты?
2. с какими шрифтами рендерятся страницы, если НЕ устанавливать микрософтовские?
Из преимуществ — пересборка и запуск грозди контейнеров в нужном порядке до запуска интеграционных тестов, остановке и удаление всей этой кухни — после. Всё это — по одной команде mvn verify без внешних инструментов оркестрации и шелловских скриптов.
Из недостатков — разработчики плагина не всегда успевают догнать быстро развивающийся докер. Нужно потратить порядочно времени, чтобы сконфигурить плагин. Ну и сам факт использования лишнего звена в системе.
ssh удобен тем, что позволяет и выполнять команды, и переписывать файлы, FTP c SSL\TLS тоже нагружает проц
по поводу модификации lighttpd.conf — спасибо, взял на заметку, на досуге попробую
кстати, за линку — спасибо, пригодится
ок. подловили на опечатке
> Чем nginx так кардинально отличается от бортового lighttpd?
критерием для выбора было потребление памяти
> WinSCP хорошая штука, но слово Win ее немного ограничивает виндой.
использование ssh не ограничено ни а) командной строкой, ни б) виндой
не нравится слово win — выберите любой другой гуй-клиент
>Функция MyCloud — обеспечить доступ к хранилищу без пробросов портов на роутере
соглашусь — это можно считать преимуществом
это также можно считать недостатком — вы коннектитесь к чужому серверу, чтобы получить доступ к своим данным
> Вы через веб расшариваете диск? А чем это отличается от встроенного WebFiles?
не только расшариваю диск, но и хостю галерею
> Хотите перенаправить корень веба с /var/www/web в другой каталог
не хочу
> подправьте соответствующим образом /etc/lighttpd/lighttpd.conf
смысла нет, этот файл перетирается при перезагрузке
> В общем все ваши вопросы, похоже, от не знания матчасти
вопросы были не мои, а ваши
общего у них:
1. раздавать файлы с хранилища в интернет
2. заливать файлы на хранилище из интернета
> fun_plug безусловно чудная штука, но у него есть большущий минус — command line only
установленный ngnix «используется» удаленным пользователем через браузер а не через command line
установленный sshd обслуживает также WinSCP — вполне гуёвое приложение
туда же можно записать trаnsmission и массу другого софта
лень топтать клаву — наслаждайтесь мышкотыкательством на здоровье
параноику очевидны преимущества своего веб-сервера перед длинковским облаком
а для обывателей — ну пусть хотя бы знают, что есть альтернативы коробочному софту
после того, как посмотрел на расход памяти и скорость передачи данных, отказался от MyCloud в пользу поднятых на нём же ngnix и sshd
была очень годная статья на хабре про эту железяку habrahabr.ru/post/155557/
у «Лаборатории Касперского» есть исходный код трояна
Лоуренс Лессиг «Свободная Культура»
плохой совет.
когда сосредоточены на поведении — имитировать бурную деятельность гораздо проще, чем показывать результат
диафрагма f16 на 7D неоптимальна — т.к. превышает дифракционный предел и ухудшает резкость
тут годная статья по поводу и калькулятор
www.cambridgeincolour.com/tutorials/diffraction-photography.htm