Мігруємо з IIS на Docker. Досвід та поради

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Всім привіт! Я Максим Усатенко, .NET розробник у компанії TELEMART.UA, та сьогодні я хочу поділитись досвідом своєї команди, а саме як ми переїхали з морально застарілого IIS на базі Windows Server 2016, на Docker.

Навіщо все це

Причин було немало. Для структуризації та наглядності далі я наведу таблицю. Попереджую, що саме ці причини — це пріоритети бізнесу нашої компанії, тобто це не є чимось обов’язковим або золотим стандартом.

Причина міграції

Опис

Чи вирішена проблема

Zero Downtime Deploy

Кожен реліз раніше — це повна зупинка сайту та всієї компанії. Downtime навіть на декілька секунд — це втрачені клієнти та збитки. Раніше нам доводилося проводити релізи якомога рідше, та у часи з мінімальним навантаженням.

Безумовно, так. Тепер неважливо, скільки зараз юзерів на сайті. Ми можемо проводити реліз по п’ять разів на день.

Моніторинг у prometheus та логування за допомогою ELK

Раніше логування було дуже примітивним да незграбним. Мабуть, так логували ще наші діди, а саме: звичайні файли у самому проєкті. По-перше, було дуже незручно шукати помилку, а по-друге, не всі мали до них доступ, тому що вони знаходилися на самому прод-сервері.

Що ж до моніторингу, то його, можна сказати, зовсім не було.

Цілком. Тепер фільтрувати логи, шукати щось — це одне задоволення. А моніторинг на базі prometheus дуже допомагає при підтримці та пошуку неполадок.

Можливість реплікації сервісів

Ми маємо так звану SOA — service oriented architecture. А як відомо, сервіси бувають різні: IO-bound, CPU-bound, або прості примитивні CRUD.

Ми дуже хотіли отримати можливість реплікувати CPU-bound сервіси задля підвищення часу відповіді. На звичайному IIS це можливо, але дуже не зручно. Нам був потрібен зручний оркестратор.

100% так. Тепер змінювати кількість інстансів стало дуже легко. Ми використали Docker Swarm.

Адміністрування ресурсами в Docker

Це, по-перше, безпека інфраструктури та стабільна робота самого серверу. Сервіс може просто лягти під час DDOS атаки та з’їсти усі ресурси, або мати у собі звичайний while(true).

Безумовно, так. Тепер задавати обмеження для контейнерів — це дуже легко та зрозуміло.

Редагування appsettings.json без рестарта сервісу

Так, сам dotnet, починаючи з core-версій вміє підтягувати конфіги у runtime, але у нашому кейсі багато змінних було перевизначено у змінних сеердовища на Windows, та це вже потребувало рестарту.

Зараз до кожного контейнера зроблено mount до хосту, де знаходяться конфігураційні файли.

Далі на цьому зупинюсь детальніше, але вже зараз відмічу, що все працює безвідмовно.

Уніфікування середовища виконання

Раніше проблеми по типу «А на моєму компі працює» були для нашої команди дуже звичайними. Ми витрачали достатньо багато часу на фікс проблем з локалізацією та іншими кепськими налаштуваннями Windows.

Як усі знають, Docker-контейнер працює однаково всюди. Неважливо, яке це середовище, які налаштування хостової ОС.

Після міграції не було жодної проблемі з цим.

Моральне застаріння серверної OS на базі Windows та дуже маленьке ком’юніті

Кажучи чесно, підтримувати сервер на Windows не приносить ніякого задоволення, а маленьке ком’юніті ускладнювало вирішення проблем.

Ubuntu 20.04 має велике ком’юніті, на будь-яке питання завжди є відповідь. А сама технологія Docker дуже перспективна та активно розвивається.

Старе поточне залізо

Нашому старому серверу вже 6 років, за цей час усе змінилося, dedicated сервер з такими же ресурсами, але свіжим залізом коштує стільки ж, але набагато швидший.

Якщо нам вже необхідно переїхати на новий сервер та все одно буде downtime, то чому б не оновити технологічний стек та вирішити декілька проблем.

Проблема вирішена. Нове залізо справді гарно показало себе за навантаженням.

Перш ніж розпочнемо, хочу зазначити, що матеріал може бути корисним для .NET розробників та DevOps-інженерів, але й PM зможуть знайти для себе дещо цікаве, щоб у майбутньому мати змогу ухвалити рішення з необхідністю самої міграції. Також вам потрібні базові знання Docker. Я не буду зупинятись на тому «Що таке Docker».

Увесь переїзд зайняв майже пів року. Звісно, можна було б оперативніше, але ми не квапились, а війна внесла свої корективи у ведення бізнесу. Стаття виявилась велика, тому я вирішив поділити її на 5 розділів.

Пару слів про нашу інфраструктуру в цілому, щоб ви мали змогу трішки уявити це, та було легше орієнтуватись по ходу статті. Ми маємо SOA — service oriented architecture. Усього 8 сервісів на .NET6, клієнт на WPF та сайт на PHP. Одна велика база на MySQL, з якою комунікують майже усі сервіси. Також є ще декілька окремих баз: Redis, MongoDb та Postgre, вони добре вирішують свої задачі, але вони дуже маленькі у порівнянні з MySQL.

Комунікація між сервісами у 99% випадках — це класична REST-архітектура, винятки становлять WebSocket на базі фреймворка SignalR та gRPC.

Хочу звернути вашу увагу на те, що ми маємо орендований dedicated сервер. Деякі проблеми та рішення бувають тільки у нашому випадку та не стосуються cloud. Тому якщо у вас усе побудовано у клауді, можливо, буде інший план міграції.

Багато нюансів при міграції я пропустив та не розповідав у цій статті. Описати кожну деталь просто неможливо за раз. Я намагався зосередити увагу саме на принципі міграції та її ключових етапах. Звісно ж, для кожного проєкта план міграції буде відрізнятися. Наприклад, у нашому кейсі, окрім переїзда на Docker, ми запланували переїзд бази на окремий сервер, та RW-RO реплікація для MySQL. З цим також було багато проблем, але у цій стаття я сфокусуюсь саме на зв’язці dotnet-docker.

Покроковий план

Цей план розробили на самому початку цього шляху. Щось було вже готове на той момент, щось потребувало декілька місяців на реалізацію. Головна задача була зробити все надійно, безпечно, з мінімальним downtime.

Також важливий момент: ми не хотіли весь спрінт реалізовувати тільки міграцію. Наша задача була зробити її максимально непомітно для самого бізнесу, тому ми не витрачали більше 20% часу спринту на неї. Звісно ж, якщо 100% часу команди пішло на міграцію, вона пройшла б набагато скоріше. Отже, перейдемо до покрокового плану:

  1. Усі сервіси повинні бути написані на .NET core 1.0 або новіших версіях.
  2. Підняття тестового серверу Linux Ubuntu 20.04, налаштування усієї необхідної інфраструктури.
  3. Dockerfile та docker-compose.yml для кожного сервіса.
  4. Налаштування CI/CD.
  5. Налаштування зворотної сумісності з IIS на випадок відмови.
  6. Тестування поточних задач вже на новому тестовому сервері під докером.
  7. Підняття нового продсерверу з аналогічними налаштуваннями як на тесті.
  8. Regression тестування нового проду та load-тести.
  9. Обрання дати та часу переїзду, ще один покроковий план для міграції та сама міграція.

Реалізація

  • Саме починаючи з core-версій, dotnet підтримує кросплатформенність та може бути запущений на Linux. Цей пункт у нас вже був реалізований. На той момент ми тільки-но змігрували всі сервіси на .NET 6. Якщо ви ще використовуєте .NET framework, раджу вам починати з міграції сервісів. Крім кросплатформенності, ви отримаєте значний приріст у швидкості, але це вже матеріал для окремої статті.
  • Без тестового серверу на Linux ви просто не зможете добре перевіряти працездатність сервісів, коли будете писати Dockerfile та docker-compose.yml. Так, є і десктопна версія докера, але все ж таки раджу одразу все робити на самому тестовому сервері. Так ви не тільки зможете перевірити свої контейнери, а також отримаєте початковий досвід адміністрування докера, який дуже знадобиться вам у майбутньому. На самому сервері, крім вашої інфраструктури проєкта, вам знадобиться Docker та Docker Private Registry (або можете використовувати DockerHub) для зберігання ваших образів.
  • Етап написання конфігураційних файлів я об’єднаю з налаштуваннями CI/CD. Тут вже потрібно розуміти сам процесс. Це допоможе при написанні Dockerfile та docker-compose.yml. Ми обрали TeamCity, тому що він нас цілком влаштовує, та в нас вже була експертиза у ньому, але ви можете обирати на свій смак.

Одна з дуже гарних переваг TeamCity — це можливість створення базових пайплійнів. У випадку мікросервісної архітектури це дуже зручно та економить ваш час. Ми розробили два базових пайплайни: build та deploy. Також TeamCity має хороші безкоштовні плани, яких достатньо для невеликих та середніх проєктів. У стандартному безкоштовному плані підтримується до трьох агентів, які можуть виконувати роботу.

Отже, CI/CD розділяємо на два пайплайни:

1. Build. Цей пайплайн триггериться за коммітом у git. Далі ви збираєте сам сервіс, виконуєте docker build та вже готовий image складаєте у ваш Docker Registry, тегуючи версією з файлу вашого проєкта .csproj. Більш детально дивіться на нашому реальному прикладі, це поетапний пайплайн у TeamCity:

2. Deploy. Цей пайплайн, як вже зрозуміло із назви, деплоїть готовий контейнер із Docker Registry на тестовий сервер або продакшен. Мы налаштували мануальний старт за кнопкою. Тобто спочатку ваш контейнер автоматом збирається після комміта, а потім деплоїте всього в 1 клік:

Нижче я навів наш реальний приклад деплою, але з міркувань безпеки замалював деякі змінні:

Можемо бачити, що цей пайплайн спочатку переносить docker-compose.yml файл на сам сервер, а далі виконує команду docker stack deploy. Звертаю увагу на те, що версія контейнера встановлюється як змінна середовища, а потім вже docker-compose.yml файл витягує цю змінну. Можна сказати, що уся динамічна інформація прокидається до docker-compose.yml файлу через середовище.

Щодо Dockerfile, одразу ж раджу створити власний базовий Docker Image. Так ви значно зекономите собі час, коли буде потрібно щось змінити в усіх сервісах одразу.

FROM mcr.microsoft.com/dotnet/aspnet:6.0.300
RUN apt-get update && apt-get install -y curl
# Configure web servers to bind to port 80 when present
ENV ASPNETCORE_URLS=http://+:80 \
    # Enable detection of running in a container
    DOTNET_RUNNING_IN_CONTAINER=true \
    # Set the invariant mode since icu_libs isn't included (see      https://github.com/dotnet/announcements/issues/20)
    DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=true \
    # appsettings refresh auto-detect
    DOTNET_USE_POLLING_FILE_WATCHER=true \
    # Allow to create not predefined cultures
    DOTNET_SYSTEM_GLOBALIZATION_PREDEFINED_CULTURES_ONLY=false \
    # Set Kiev timezone
    TZ="Europe/Kiev"
EXPOSE 80

Це наш базовий образ, на базі якого вже побудовані образи для всіх сервісів. Можемо бачити, що за основу використано образ від Microsoft для ASP.NET core 6 сервісів. Встановлено curl, він потрібен для healthcheck у середині контейнера. Із цікавого ще відмічу встановлену змінну середовища DOTNET_USE_POLLING_FILE_WATCHER. Саме з її допомогою нам не потрібно перезапускати сервіс, коли редагуємо appsettings.json, який примонтували у сам контейнер. Dockerfile самого сервіса дуже мінімалістичний саме завдяки тому, що усю однакову логіку між сервісами ми винесли в базовий образ:

FROM my-own-registry.com/telemart.base:6.0
RUN apt-get update && apt-get install -y apt-utils libgdiplus libc6-dev
WORKDIR /app
COPY out .
ENTRYPOINT ["dotnet", "Telemart.Calculator.Service.dll"]

Далі пропоную розглянути docker-compose файли. На жаль, неможливо так само робити базові файли, тому багато логіки довелось копіювати. Можемо бачити багато налаштувань через змінні середовища, наприклад ${VERSION}, ${ENVIRONMENT} та інші. Це саме ті змінні, які ми задавали у пайплайні build. З їхньою допомогою ми задаємо версію контейнера, середовище виконання та ще багато іншого.

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

version: '3.7'
 
services:
 telemart_calculator:
   image: my-own-registry.ua/telemart.calculator:${VERSION}
   environment:
     - ASPNETCORE_ENVIRONMENT=${ENVIRONMENT}
   labels:
     - telemart-metrics=true
   ports:
     - "127.0.0.1:${PORT_PREFIX}003:80"
   deploy:
     replicas: 2
     update_config:
       parallelism: 1
       order: start-first
       failure_action: rollback
       delay: 10s
     rollback_config:
       parallelism: 1
       order: stop-first
     resources:
       limits:
         cpus: '12'
         memory: 8000M
   healthcheck:
     test: curl --fail http://localhost:80/health || exit 1
     interval: 10s
     timeout: 10s
     retries: 5
   logging:
     driver: gelf
     options:
       gelf-address: "${GELF_ENDPOINT}"
       tag: telemart${ENVIRONMENT}.calculator
   volumes:
     - /config/${ENVIRONMENT}/shared.json:/app/shared.json
     - /config/${ENVIRONMENT}/calculator.json:/app/calculator.json

Коли ми розібралися з двома основними конфігураційними файлами Dockerfile та docker-compose.yml, настав час питання: де їх розмістити? Рекомендую їх класти кожен до свого сервіса поруч із файлом проєкту .csproj. Дуже гарно, якщо ці файли завжди будуть на одному рівні, та шлях до них буде відрізнятись тільки назвою самого сервіса. Це дуже допоможе вам під час написання пайплайнів — ви легко зможете винести шлях до базового пайплайна та задавати тільки назву самого сервіса.

Ще, як варіант, можна уніфікувати файл docker-compose.yml та перевизначати лише змінні для кожного сервісу. Там вам не доведеться редагувати при базових змінах файли у всіх сервісах.

У нашому кейсі зворотна підтримка IIS не потребує ніяких зусиль, але треба пам’ятати про це та мати план відкату. Наприклад, ми ще не працювали з окрестратором Docker Swarm та не знали, які факапи можуть з цього вийти.

З тестуванням усе доволі легко. На тестовому середовищі ми не знайшли ніякого багу, все працювало так, нібито ми завжди були на докері. Увесь поточний спрінт, таски вже тестувались на новому Linux сервері.

Окремо відзначу load та stress тестування. Для цього я обрав artillery.io, для мене це чудовий та зручний інструмент з тестування. Основна задача була перевірити те, що новий сервер не менш швидкий у порівнянні з минулим. Старий сервер нам довелося тестувати о п’ятій ранку, коли на сайті мінімальна кількість користувачів. Новий ми вже мали змогу перевірити, коли нам зручно. Перш за все, нас цікавила максимальна кількість запитів у секунду, коли наш сервер давав відповідь 200 OK у 99% випадках. На жаль, я не можу озвучувати конкретні цифри з міркувань безпеки, але за допомогою нового заліза та реплікації високонавантажених сервісів, наша пропускна здатність зросла майже втричі. Ми намагалися охопити якомога більше методів, щоб імітувати реальне навантаження поточного сайту TELEMART.UA.

З новим продсервером теж усе зрозуміло. Беремо залізяку або клауд, робимо майже ті ж самі налаштування, як і на тесті. Різниця може бути лише у конфігах та DNS. Цей крок — один з останніх, тому що інфраструктура коштує недешево, та чим пізніше ми її купимо, тим вигідніше для компанії. За цей період, доки ми не мігрували, нам доводиться платити за обидва продсервери одразу.

Коли все протестовано, ми почали обирати дату переїзду. Тут усе просто: переїжджаємо тоді, коли мінімальне навантаження. Для нас це був період з 4 до 6 ранку. План був наступний:

  1. Зупиняємо поточний продакшен.
  2. Робимо дамп бази та розгортаємо його на новому сервері (це найдовший крок, який зайняв близько години через розмір бази).
  3. Змінюємо DNS TELEMART.UA на новий IP-сервера.
  4. Запускаємо інтеграційні тести, які охоплюють якомога більше різних сервісів. Це найшвидший спосіб зрозуміти, чи все працює нормально.

Хочу звернути увагу на те, що я опустив деякі операції при міграції. Вважаю їх не цікавими, тому що вони стосуються тільки нашого бізнесу. В цілому, все пройшло нормально. Так, помилки були, але вони були пов’язані тільки з переплутаними конфігами та нашою необачністю. О сьомій ранку 99% функціоналу компанії вже працювало стабільно.

Отже, що ми маємо в результаті переїзду:

Звісно, я не відобразив багато нюансів на зображенні, але найголовніше — це розуміння усього флоу: хто з ким взаємодіє. Звертаю увагу на те, що NGINX працює у ролі зворотнього проксі-сервера, а потім вже оркестратор Docker Swarm розподіляє трафік за інстансами.

Окремо відзначу один з наших етапів міграції, а саме розгортання бази MySQL на окремому залізі. Раніше всі сервіси та база працювали разом, але їм у пікові часи не вистачало ресурсів. Під час розгортання одразу зробили реплікацію MySQL master-slave, тому що було декілька високонавантажених сервісів, які тільки запитували дані з бази, але ніколи їх не редагували. На жаль, зараз не можу багато сказати про позитивні моменти, тому що ще не пройшло багато часу, але із мінусів назву проблему, коли періодично slave починає відставати від основної репліки аж на пів години.

Також звертаю вашу увагу на один важливий факт: контейнери всередині докера взаємодіють по внутрішній мережі докера і не виходять за його рамки без потреби. Це дає приріст у продуктивності.

Проблеми та нюанси

На жаль, для нашою команди це був новий досвід, тому кожен етап для нас був новим, ми щось вигадували, гуглили, витрачали багато часу на елементарні пункти, але врешті-решт все вдалося. Далі я наведу кілька основних проблем, з якими нам довелося зіткнутися:

  • Вибір оркестратора. Сам Docker — технологія контейнеризації, але не оркестрування. Ми витратили багато часу на вибір, та у якості оркестратора ми обрали Docker Swarm. Саме завдяки ньому ми маємо змогу реплікувати сервіси, а за допомогою команди docker stack deploy робити це без даунтайму.
  • Одразу ж відповім на питання: чому не Kubernetes? Нас цікавила, перш за все, програмна відмовостійкість, яку дуже гарно вирішує Docker Swarm. Бачу сенс у Kubernetes тільки коли ми маємо великий кластер серверів, та крім програмної відмовостійкості бажаємо ще й апаратну.
  • Отримання версії сервіса з .csproj. Ми не хотіли кожен раз при білді мануально вказувати версію, тому вирішили вказувати її у файлі .csproj у форматі <Version>1.2.3</Version> та на етапі CI/CD витягувати її звідси. Це виявилось не дуже легкою задачею. Спочатку ми вирішили це завдяки тулзі exiftool під Linux, але потім трішки спростили це та спарсили версію руками. Це рішення не дуже красиве, але воно працює та не потребує зайвих залежностей:
  • version=$(sed -n 's/.*<Version>\(.*\)<\/Version>.*/\1/p' $(find -name %startup_project%))
  • Не використовуйте образи «:latest». Під час налаштувань TeamCity зіткнувся з дуже дивовижною проблемою. У мене перестав працювати етап dotnet build. По-перше, він тільки вчора ввечері працював, а по-друге, чому там ламатися? Як пізніше виявилось, Microsoft у версії dotnet 6.302 зробив один дуже маленький breaking change, пов’язаний з форматом команди виводу результату, яку навіть я ніколи не використовував та не чув про неї. А от TeamCity активно її юзав, і він просто зламався на цьому етапі. Цієї проблеми б не було, якщо я використав би базовий образ з конкретною версією dotnet, але в мене було вказано просто aspnet:6.0, що означало останню версію шостого дотнета.
  • SignalR та реплікація. Не можу не згадати ще один дуже важливий факт: SignalR не підтримує реплікацію сервісів із коробки. Для цього необхідно використати так звані Sticky сесії. На момент написання статті ми їх ще не реалізували, тому поки не можемо збільшити кількість реплік для цього сервісу більше 1. Рекомендую замислитись над тим, щоб real-time сервіс був зовсім окремо у архітектурі.
  • Правильне налаштування NGINX. У нашому кейсі була помилка: після міграції ми зрозуміли, що в нас протокол HTTP/2 зачинено для gRPC. Тому рекомендую дуже ретельно передивитись технологічний стек, а саме, якi протоколи комунікують.
  • Обачність та більш детальне планування самої міграції. Це не пов’язано із самим докером або технологіями. Потрібно розуміти, що інфраструктура — це не тільки декілька сервісів та БД. Завжди є щось, що додавали колись до вас, та воно якось працювало. У нашому випадку це була дуже маленька програма, яка мануально рахувала ціни та складала до бази даних. Проблема виявилась у тому, що коннект до бази в неї був захардкожен, ісходників давно не має, а декомпілювати Delphi не така й проста задача. Ось так після міграції нам довелося у дуже оперативному темпі за добу дописувати прототип програми, який ще не був готовий до використання на проді.
  • Оверхед за рахунок віртуалізації. Все ж таки, якщо намагатись порівняти швидкість dotnet сервіса, який хоститься під звичайним NGINX або IIS з сервісом під Docker, то у першому випадку буде дуже невеликий виграш у швидкості за рахунок відсутності віртуалізації як такої. Але насправді ця різниця у кілька мілісекунд не грає ніякої ролі, та зовсім сходить на ні, коли наростає навантаження. Тут потрібно розуміти, що різниця між 20 та 40 мс не так важлива, як різниця між 500 та 1500 мс під час навантаження.
  • Реплікація сервісів — це не панацея. Хочу попередити, що реплікація має сенс для сервісів, які активно використовують CPU. Якщо ваш сервіс просто читає з Redis, то реплікація зовсім не підвищить швидкість, а також зробить тільки гірше для ваших ресурсів. Тут одна порада — експериментувати. Складно описати словами ту грань, коли сенс є.
  • Healthcheck та HTTP/2. Якщо ваш сервіс працює тільки за HTTP/2 на фреймворку gRPC, то стандартний curl працювати не буде. Треба додати лише --http2-prior-knowledge до нього. На виході healthcheck буде виглядати наступним чином:

curl --http2-prior-knowledge --fail http://localhost:80/health || exit 1

Ще як альтернативу можу порекомендувати підняти окремий порт для моніторинга та healthcheck. Якщо curl ще можна подружити з HTTP/2, то агент prometheus, на жаль, ще ні.

Висновок

Якщо коротко: все було круто. Усі наші плани здійснені. Зараз новий сервер працює стабільно та його дуже легко підтримувати. Уся наша команда отримала дуже цікавий та корисний досвід. Попереду ще великий шлях с оптимізування реплікацій, але вже зараз можна бачити: працює набагато швидше, ніж раньше. Окремий кайф — це деплой у TeamCity через кнопку. Раніше доводилося руками скачувати сервіс, підміняти та перезапускати його у IIS.

З боку IT все гарно та зручно, а які ми маємо переваги для бізнесу? По-перше, це стабільність. Вона обумовлюється оркестратором, якого раніше взагалі не було. По-друге, більш високий uptime. Це було досягнуто завдяки zero downtime deploy. По-третє, нове залізо та реплікація зробили свою справу — зменшився час відповіді від навантажених .NET сервісів, а це позитивно вплинуло на конверсію.

Сподіваюсь, ця стаття комусь була цікава та корисна. Дякую за увагу)

Де краще — тут чи там, — залежить від того, де задано питання. Симон Моісеєв

👍ПодобаєтьсяСподобалось14
До обраногоВ обраному5
LinkedIn

Найкращі коментарі пропустити

Название стоило бы как-то исправить, чтобы оно не было таким алогичным. «Переезд с IIS на Docker» звучит примерно так же, как «вместо дивана мы стали использовать вентилятор».
UPD. Посмотрел сравнительную таблицу. Это ж вообще бред сумасшедшего. Такое впечатление, что те кто эту таблицу составляли, вообще не понимают, какой инструмент для чего используется.
Про логирование и DDoS — это где-то за гранью.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Загаловок звучит примерно: «как я поменял Java на Linux»

Для тих хто не працював з IIS: на одному сервері достатньо копіюванням трьох(частіше одного) файлів робиться деплоймент будь-якої складності. Application Pool дають можливість міняти конфіги прямо на веб сервері в UI, без downtime і зупинки веб-сайту.

На самом деле все еще проще: в настройках сайта можно поменять директорию на новую, как делает Octopus deploy, например.

це не простіше, це одне і те ж.

в k8s вообще не надо ничего копировать, ни лезть руками в деплойменты, ни подменять директории на куче хостах. Даешь команду обновить имейдж деплоймента и оно бесшовно перезапустит приложение без даунтайма. Сначала поднимается новый контейнер до статуса readiness, потом ждет определенное время, пока остановится старый контейнер, та и понятие «конфигов» там другое

Кожен реліз раніше — це повна зупинка сайту та всієї компанії. Downtime навіть на декілька секунд — це втрачені клієнти та збитки. Раніше нам доводилося проводити релізи якомога рідше, та у часи з мінімальним навантаженням.

Тут явно проблема не в IIS, і явно докер це не причина вирішення

Раніше логування було дуже примітивним да незграбним. Мабуть, так логували ще наші діди, а саме: звичайні файли у самому проєкті. По-перше, було дуже незручно шукати помилку, а по-друге, не всі мали до них доступ, тому що вони знаходилися на самому прод-сервері.

Ну це також не в IIS проблема, і докер явно це не основна причина вирішення.

Не розумію сенсу таких статей, ви IIS звинувачуєте що деплоймент був не ок і логи були коряві? Ха.

Сам Docker — технологія контейнеризації, але не оркестрування. Ми витратили багато часу на вибір, та у якості оркестратора ми обрали Docker Swarm.

Робити такий вибір в 2022 і тим більше рекомендувати його іншим через статтю.. Ви впевнені що ви робите?
Та і взагалі, зараз вже сам по собі docker як технологія використовуюється хіба шо для локальної розробки, і то вже достатньо інструментів його позбутися. Ну а на серверах взагалі не використовують.

Іще доволі дивним виглядає вибір team city якщо ви до цього його не використовували. Тому що всі ці ручні налаштування степів і скриптів теж вчорашній день. Набагато легше, зручніше, надійніше шось накшалт github actions.

на кшалт

це слово-паразит від пшеків, якого немає у мові

Такого дійсно не має. Але є запозичине — на кшталт.

Да вы правы лучше сделать так как например, описано здесь.https://docs.krustlet.dev/howto/wasm/

Хлопцы, а зачем на докер это уже 2022 уже не актуально. Даже сам автор докера это признал kubesphere.io/...​assembly-replace-docker
training.linuxfoundation.org/...​erization-more-efficient

if(total_products < 300){  $parent_container.find('.privat_error').html(lang['catalog']['Not enought limit']); }else{  $parent_container.find('.privat_error').html(lang['catalog']['Overlimit']); }  $parent_container.find('.privat_error').show();

Там на фронті сплошне спагетті з мертвого jquery та jquery ui.
telemart.ua/...​.index.js?v=2.528&lang=ru
Схоже у вас проблеми були не тільки з беком а ще і з нормальним фронтендщиком, я б взагалі відмовився підтримувати цю лапшу. Зараз тільки складний фронт на ангулярі, реакті або vue з тайпскриптом, інше у смітник.

я за фронт не отвечаю) мое дело это бэк.

Ты опять как ребенок. Не существует доказательств, что

ангулярі, реакті або vue з тайпскриптом

чем то лучше

jquery та jquery ui.

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

складний фронт

Страничка с ноутбуками на продажу. уууу как сложно. без ангулара ну никак

Немає значення 500 там ноутів чи 5 млн. Розетка зроблена на ангулярі і швидко працює. Є категорія девів, які відкрили таску, зробили її на відїб...ь, самі протестили та закрили. Потім ще поверх шмат лайнокоду дописується і так каскадом. Потім чел звалює на нову галеру, садиться нова команда і виявляється, що все написане лайно тупо треба дропати, або втопитися у гнилому болоті з лайнокодом. Дуже схоже що ти підпадаєш у цю категорію. Вчи контейнерізацію та принципи побудови складного гуї та потім пиши щось біль розумне, а не маячню

швидко працює, але фільтри застосовуються по одному))

складний фронт

Зачем писать сложный код, если можно простой? Чтобы брать деньги за поддержку?

Як ви відрізняєте складний та простий код для інтернет-магазину? Якщо ткм спагетті-код без ніякої модульності, як ви це збираєтесь підтримувати?

Микросервисы и контейнеризация нужны на 0.5% всех проектов. Вероятность того что ваш проект в этом нуждается ну оочень маленькая.

Це мабуть ти не працюєш або не працював на нормальних проектах, якщо сервіс не працює у контейнерів то буде завжди проблема «у мене все працює» тощо локальне середовище відрізняється від проду. Друге це горизонтальний скейлінг

Горизонтальний скейлінг у мікромагазині? Може їм ще AI/ML прикрутити для вивчення поведінки клієнта і показу релевантних порад?

Там вообще можно было на Проме сделать и не париться с докерами, дотнетом и т.д. и работает изкаропки и намного дешевле обойдется

Генератор ПК на основании совместимости комплектующих как на проме реализуете?)

Тану... так просто зручніше. Навіть на петпрожект на 5+к рядків. Мікросервіси просто зручніше.

Ви впевнені, що розумієте, що таке мікросервіси? СТО Касти тут на Доу нещодавно описував, що прагнення до мікросервісів — це карго-культ

Послушал матюкливую речь этого «СТО» там кроме clojure все остальное говно, рассказывал как он осилил Графану и Кибану, который любой синиор должен знать, весьма спорные моменты в его утверждениях, есть места где лучше монолит, а где микросервисы. Нужно четко осознавать и думать что где использовать

Магаз не выдает фискальный чек hotline.ua/...​ges/d/h/61d43f52c908e.jpg

— не указан ИНН продавца у которого куплен товар
— бумажка называется «видаткова накладна»

Docker Swarm

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

періодично slave починає відставати від основної репліки аж на пів години.

это у вас очень серьезный залет, у меня максимум 1-2 секунды было на очень большом проекте, надо искать причину

SOA — service oriented infrastructure.

architecture

Хочу попередити, що реплікація має сенс для сервісів, які активно використовують CPU.

Это как? Давайте представим, приходит запрос и там CPU-bound вычисления на эндпойнте и среднее время выполнения запроса, к примеру, 2сек. По вашему, если я запущу 2 контейнера, то запрос станет за 1 сек обрабатываться?

1. Спасибо, отпечатался (

2. Если более развёрнуто, то тут скорость может быть достигнута когда не хватает потоков по какой либо причине, в случае 32 битного процесса когда инстанс ограничивается в 4гб, если инстанс не умеет держать нужное кол-во коннектор куда либо, или одновременное кол-во открытых файлов. В случае идеального вакуумного сервиса репликация действительно бессмысленна.

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

в случае 32 битного процесса

2022 год на календаре

Там упоминается коннектор к бд на Delphi, оттуда видно и растет сервер на винде и 32 бит. Там еще и бд наверное foxpro или Firebird. Я дельфи наверное видел последний раз в универе и на заводе проект с 90х годов одного пенсионера открывал

Я в 2016-17 ещё пилил сервисок на борландовском билдере) туда даже фичи добавлялись чутка)

О молодість, о юність парубоцька ))

Это как? Давайте представим, приходит запрос и там CPU-bound вычисления на эндпойнте и среднее время выполнения запроса, к примеру, 2сек. По вашему, если я запущу 2 контейнера, то запрос станет за 1 сек обрабатываться?

Если предствить при этом, что обработка запроса использует все выделенные CPU ресурсы, то обработка двух одновременных запросов на одном инстансе будет занимать четыре секунды. А если добавить еще один инстанс и балансер перед ними поставить, то два запроса выполняться за две, а не за четыре секунды. Это называется горизонтальным масштабироваением.

Именно так, но автор написал, что у них одна нода и контейнеры он создает в кластере из одного инстанса, как это может помочь при cpu-bound вычислениях хз

Он там, вроде, говорил, что к ним это не применимо из-за текущего сетапа и SignalR. А если говорить в общем, то на одном сервере может крутиться не только API, а и другие сервисы, для которых выделяются определенные рерусрсы, а не все доступные на сервере. Поэтому, если под API выделяется условно 2 CPU, то заскейлив этот сервис получим 2 инстанса по 2 CPU и пропускная способность удвоится. При прочих равных это будет равносильно одному инстансу с 4 CPU, но с большей availability.

Одразу ж відповім на питання: чому не Kubernetes? Нас цікавила, перш за все, програмна відмовостійкість, яку дуже гарно вирішує Docker Swarm. Бачу сенс у Kubernetes тільки коли ми маємо великий кластер серверів, та крім програмної відмовостійкості бажаємо ще й апаратну.

Не зрозумів агрументацію. Що ви маєте на увазі під апаратною відмовостійкістю в контексті Kubernetes? І якщо він вирішує і «програмну» і «апаратну», то чому б його не використовувати? Які ще критерії ви розглядали?

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

А если сравнивать докер swarm и кубернетес без «аппаратных фич», то как по мне, докер проще в освоении. Учитывая то что у команды еще не было опыта вообще в этом, то простота освоения была достаточно важным фактором.

Я би про це сказав в статті — що «Swarm простіший у вивченні ніж Kubernetes і його достатньо для вирішення задачі, ...», так на мій погляд пояснення буде більш зрозумілим.

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

Отдельно непонятно для чего Swarm на одной ноде, если, вероятно, можно было обойтись docker compose. В Swarm, ведь, дофига неприятных ограничений.

Тем не меннее, круто, что поделился опытом, уверен, что в комментах соберешь много полезного филбэка!

Спасибо за отзыв) а какие у вас вышли проблемы потом? Мы пока ещё не долго на нем сидим, пока что ничего плохого не заметили.

За предыдущие несколько лет ситуация могла поменяться (хотя swarm активно не разрабатывается, на сколько мне известно), но в то время он, например, не умел создавать директории на хосте и это приходилось делать руками или отдельными скриптами. Не умел подтягивать .env файлы — тоже писались отдельные скрипты, у него было много других ограничений по сравнению с docker-compose. Не умел запускать привелигированные контрейнеры, которые были необходимы на тот момент для сбора crash dump-ов средствами .net. В общем он добавлял проблем, которые в K8s уже решены тем или иным образом.

Но K8s для одного хоста — это, конечно, overkill (он сложнее в изучении и администрировании). Поэтому для одного нода я бы, все же, шел по пути docker-compose.

Так Docker, docker swarm и кубер это вообще разные вещи. Если не знать чистого докера, то вообще очень странно кого держите на проекте

Простіше не означає що його взагалі потрібно «осваівать» :)

TELEMART.UA

кадри вырішують все
цей на внутрішньому ринку

Мігруємо з IIS на Docker.

так а в докері що веб сайт крутить?
apache чи той же iis
точно не Docker

заголовок має бути

як ми перенесли !Core.net Ґ(не плутати з .Net)! з Windows server + IIS в докер контейнер з linux

бо якщо .net в теоріі теє працюватиме в докері
тільки з Windows + IIS

тут теж весело

Навіщо все це
Причин було немало. Для структуризації та наглядності далі я наведу таблицю. Попереджую, що саме ці причини — це пріоритети бізнесу нашої компанії, тобто це не є чимось обов’язковим або золотим стандартом.

Zero Downtime Deploy

ну це і IIS може. навіть один інстанс
а якшо вебфарма чи лоа балансер то взагалі без проблем
питання тільки в плануванні розгортання

ну і т.д.

добре що модернізувалися, для резюма рядочок гарно мати
а так ...

К шындовс с IIS еще осталось добавить хостинг на домашнем компе для лучшей надежности и простоты

Якщо нам вже необхідно переїхати на новий сервер та все одно буде downtime, то чому б не оновити технологічний стек та вирішити декілька проблем.

Переписали бы тогда уже по дороге приложение на каком-нибудь Python или NodeJS. Все равно ж переезжать, downtime и вот это вот все.

Мігруємо з IIS на Docker
Усі сервіси повинні бути написані на .NET core 1.0 або новіших версіях.

Расходимся, посоны. Из названия я подумал, что у вас было ASP .NET MVC приложение, которое не может работать без IISа, а вы его как-то переписали ловко, без переписывания всего. Если у вас изначально приложения были на .NET Core, зачем вы их хостили под IISом?

Усі наші плани здійснені.

Я так понял, целью было именно это:

Уся наша команда отримала дуже цікавий та корисний досвід.

В таком случае автор молодец.

Изначально был IIS и .NET framework. Потом плавно смигрировали сервиса на .NET core когда он появился еще в 2017 если не ошибаюсь. И вот только сейчас пришли к миграции на докер.

И вы это все городили ради вашего сраного интернет-магазина?

Почему анонимно?) Открой лицо, расскажи о своем бизнесе, мне будет интересно послушать что городил там ты.

Оверхед за рахунок віртуалізації

Пожалуйста, прочитайте о том, как работает Docker. Пожалуйста!

Давайте либо обсуждать по существу, либо я вообще не вижу смысла в Ваших комментариях. Оверхед за счет виртуализации был наглядно показан нагрузочным тестированием, которое проводил лично я. На малых нагрузках под artillery IIS быстрее. Docker показал эффективность при нагрузке свыше примерно 10 rps. И да, я много что читал и знаю о докера ;)

Свыше 10 запросов в секунду? Это сколько примерно?

Ми дуже хотіли отримати можливість реплікувати CPU-bound сервіси задля підвищення часу відповіді.

Щито?!

Название стоило бы как-то исправить, чтобы оно не было таким алогичным. «Переезд с IIS на Docker» звучит примерно так же, как «вместо дивана мы стали использовать вентилятор».
UPD. Посмотрел сравнительную таблицу. Это ж вообще бред сумасшедшего. Такое впечатление, что те кто эту таблицу составляли, вообще не понимают, какой инструмент для чего используется.
Про логирование и DDoS — это где-то за гранью.

Если кроме негатива у Вас есть аргументы к своим словам, или возможно дельные рекоммендации, то расскажите о них)

Я боюсь, что объём комментариев к каждому пункту превысит объём статьи.
Если кратко: вы приняли в принципе правильное решение по миграции, опираясь в то же время на абсолютно бредовую аргументацию. Иногда это работает. Но зачастую приводит к печальным результатам.

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

Кроме слова «Бредовая аргументация» у вас аргументы будут?)

Все уже поняли, что вы написали 5 монографий по докеру и великий айти эксперт, умеете проводить собеседования и вообще C# назван в вашу честь.

Возможно вы все таки расскажете по существу с чем вы не согласны?)

Согласен с предыдущем оратором. Как инструмент контейнеризации может заменить вебсервер? И да контенерация != виртуализация.

Так и не может. Конечно будет еще NGINX, но на нем я абсолютно не вижу смысла останавливаться. В этой статье я рассказал именно о нюансах докера. Название в данной статье в первую очередь пёстрый заголовок. Если бы называлось: «Переезжаем с виндоус сервера под IIS на линукс с докером под NGINX» , то да, было бы правильнее с технической точки зрения, но не с точки зрения лаконичности и читабельности.

При чем тут Nginx? dotnet run <*.dll> какой веб сервер использует ?=)

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

Судя по тому что автор так и не ответил... ;)

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

Я просто задал вопрос, понимаете ли вы что происходит когда вы запускаете dotnet run и какой вебсервер поднимается

Так написал же по двум пунктам. DDoS и логирование.

Возьмите хотя бы один пункт, то же «логирование» и подумайте, является ли это реальным поводом для «переезда с IIS на Docker». Если вы реально считаете, что для того, чтобы начать использовать ELK вам нужно перенести всю инфраструктуру в Docker, то у меня для вас плохие новости.

Вы в таблицу с причинами переезда накидали кучу пунктов, которые вообще не имеют сюда отношения.

Если вы придёте к вменяемому СТО и скажите, что хотите полностью поменять существующую инфраструктуру, чтобы использовать ELK, то скорее всего услышите как минимум удивление, как максимум — очень много нелестных слов.

Ещё раз, ваша проблема не в желании использовать докер. Проблема в непонимании инструментов и задач, которые они решают.

А кто вам сказал что одна необходимость в ELK это был повод для переезда? Я описал множестве пунктов, которые суммарно для нас являются причиной. Подчеркиваю: для нас. У всех могут быть свои приоритеты, и если вам в кайф поставить докер на винду то пожалуйста.

CTO чье кредо «ничего не трогаем, а то вдруг сломаем» и даром не нужен современному проекту.

То есть вы серьезно считаете, что проблема будет в СТО, а не в том, с какой аргументацией в к нему пришли?

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

Так в этом и беда, что для решения этих проблем не нужен докер. Точнее вовсе не обязательно для решения этих проблем тащить вашу систему в контейнер.
Чтобы писать логи в ELK достаточно использовать log4stash библиотеку. И все.

От DDoS контейнеризация тоже сама по себе не спасает.

Поэтому вообще не ясно, к чему эти пункты в таблице.

Контейнеризация позволяет ограничивать ресурсы для контейнеров. Если под атаку попадает сервис и он начинает выедать всю оперативу, то он не сможет это сделать когда стоит ограничение например в 20% и сервак не упадет. Разве это не спасает весь сервак от падения? Как по мне лучше иметь 1 упавший сервис , чем весь сервак. При микросервисной архитектуре 90% юзеров даже не узнают об этом в принципе.

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

docs.microsoft.com/...​ng-sites-and-applications

Подобная реализация для нас не является удобной. В докере реализовано по моему мнению лучше.

Так в IIS есть «садик» если сервер один, когда обработка очереди запросов запускается в несколько отдельных процессов. Есть конечно ограничение, как разработчик должен хранить переменные в сессиях, точнее относительно возможности их сереализации. Так как их хранение выносится за процесс, чтоб из любого к ним можно было попасть и не прерывались клиентские сессии. На процессы можно выставить ограничения по сжиранию памяти, процессора, чтоб они перегружались. Тогда долгий процесс/запрос не мешает проскакивать мелким. Т.е. кроме фермы из серверов, на каждом еще делается садик (ферма из процессов в рамках одного сервера).

Да возможно. Спасибо за подсказку. Вижу две проблемы в этом:

1) это не удобно, по сравнению с докером.

2) маленькое комьюнити, сложно искать решение проблем.

О как! А каким боком тут винда вообще? Мне прямо интересно стало.

ELK удобно админить в контейнерах. У вас есть альтернатива по удобству? Расскажите.

ELK удобно админить можно по разному. Только вот каким образом это является аргументом для контейнеризации вашей системы?

Ну давайте с самого банального начнем. Где крутить контейнера? Облако под наш бизнес не подходит. Остается либо купить мини сервак под него либо накататить докер на винду. Как поступим?) Возможно вы знаете еще идею.

Мы ещё не решили, что контейнеры вам нужны в принципе. Я же говорю, проблема в аргументации и изложении мыслей. Вы скачите с одного на другое.

Я как раз никуда не скачу) Мне нужен ELK. Я знаю как его удобно запускать и админить в докере.
Какая проблема аргументации? Если для вас удобство использования не аргумент, то возможно это ваша проблема как CTO.

Обращаю ваше внимание на то, что мы уже с вами пишем не первый десяток комментов, и при этом от Вас я не услышал ни одного предложения как можно сделать лучше.

Предлагайте) Рассказывайте) Пожалуйста)

Я предложил и внедрил. Все работает и решает свои задачи. Если ваша задача как CTO критиковать необоснованно, то вы тоже умеете решать свои задачи.

Ваша проблема в неумении аргументировать правильно предлагаемые решения. Чтобы аргументация выглядела хоть как-то логично, нужно вытягивать ее из вас наводящими вопросами.

У меня нет никаких проблем) И не нужно мне их пытаться нарисовать.

Если что то вы не увидели в статье , то это не значит что этого нет. Я не на собеседовании перед вами и вы не мой CTO. Я вас не убеждаю никуда переезжать, мне вообще все равно.

Я рассказывал про опыт переезда. Именно НАШ опыт. Основанный на нашем бизнесе, взглядах и экспертизе.

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

Критика бывает аргументированной и пустословной.
К сожалению, в вашем случае это второй вариант.

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

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

Моя критика касалась того, что в статье отсутствует грамотная аргументация для внедрения новой технологии. Я дал наводящие вопросы по определённым пунктам. Вы не смогли эти пункты защитить.

Какой конкретно мой опыт вас интересует?

Знаєш чим відрізняється досвідчений розробник від недосвіченого. Що він якійсь помилкові рішення спримає на особистий рахунок. А досвічений спокійно сприймає що він чогось не знає чи чогось не врахував — світ айті дуже великий і швидко змінюється, щоб знати все.

Критика була доволі аргументованою, але за враженим его важко почути аргументи. Аргумент в тому, що перелічені причини для міграції насправді не є причинами для міграції.
Хіба шо можна сказати, що в 2022 році для проекта який активно розвивається нема взагалі ніяких аргументів залишатися на IIS/.NET Framework. Тільки якщо це якесь відмираюче легасі, яке дорого мігрувати.

Сейчас большой западный бизнес начинает проекты на ASP.NET Web Forms. Да. В 2022. Я это своими глазами вижу. Потому что у 100+ людей есть огромный опыт.

Це мова про німецькі ентерпрайзи, де люди сидять десятиріччями чекають поки доростуть до вищої зарплатної ланки згідно з табличкою?
Тоді вірю.
Інакше я не знаю кого вони зможуть наймати на це все мамонтокопаніє

С трудом верится, что именно «начинают».
Еще более трудно верится в то, что 100+ людей с огромным опытом в asp.net web forms, за столько лет не удосужились посмотреть что там происходит в asp.net core (mvc, webapi, razor pages) и не могут нормально стартовать проект на относительно свежей базе кода.

Какой бизнес, ты шо прикалываешь. У вас 500 ноутбуков. Перенесите это все на пром юа и дело с концом.

Облако под наш бизнес не подходит.

доречі, а чому не підходить?

Так там ще cloudflare зверху прикручен, навіщо маленькому магазину з 400 ноутами захист від ддос?

Cloudflare варто прикручувати хоча б для нормальної і безкоштовної hsts. На рахунок захисту від ddos не знаю, але чув що це доволі розповсюджений метод боротьби з конкурентами серед українських інет-магазинів

Це вже питання звичок і зручності. Якщо використовуються інші інструменти в клаудфлер то може бути просто зручно все там мати.

А летсенкрипт + клаудфлар безкоштовні вайлдкард https сертифікати.

Стоимость аналогичной инфраструктуры выходит в 4 раза дороже. Да, удобнее, но бизнес не одобрил.

Це тоді називається намагались знайти максимальне дешеве рішення, а не хмара не підходить під бізнес.

які ще аргументи, ви в базових поняттях путаєтесь. Ви точто .Net developer чи маркетолог в Docker/Telemart?

В базовых понятиях я не путаюсь.

И вам добро пожаловать в общество пустословов ;)

Андрей, а мне кажется таблица вполне сойдет, ты работал с in-proc развертыванием в IIS ? Человек же писал про ЛИЧНУЮ мотивацию переезда на конейнерезированное окружение, а не мотивацию «в целом». Там конечно не все связанно с котейнерами но по-моему аргументы вполне подходящие в их кейсе.

Техническая статья должна содержать техническую аргументацию.
А личная может быть хоть «мне логотип продукта понравился». Но это не является ни разу аргументацией с технической точки зрения. И ни один СТО не примет такую аргументацию.

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

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

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

есть просто желание «попробовать докер».

Очень часто это является истинной причиной каких-то глобальных технических изменений, добавление в решение каких-то новых инфраструктурных вещей типа NoSQL баз данных, Redis-ов и Elastic-ов. Но заворачивается это так, будто без этого очень скоро ничего уже не будет работать.

Человек принимающий решения, в ряде случаев не понимает вообще что это такое и чтобы не подавать виду, согласовывает эти изменения. Ещё в ряде случаев он понимает, что это нафиг не надо, но перед вышестоящим начальством тоже ж отчитываться о чем-то надо, поэтому почему бы и нет. И только в каком-то количестве случаев такие изменения не согласовываются. Например, когда СТО действительно понимает в T из своей аббревиатуры и при этом является одним из собственников. Я немного утрирую конечно, но только немного.

Так об этом же можно написать. «Мы хотели попробовать докер. Попробовали. Понравилось.» Это было бы честно и нормально. Но зачем-то делается попытка показать некую аргументацию, где часть пунктов вообще не к месту, а часть ну очень сильно притянута за уши. Это и создаёт негативное впечатление, как будто ни автор ни команда не понимают, зачем на самом деле они делают то, что делают.

А если на статью наткнется кто-то из людей, которые деньги за этот «опыт команды» со своего кармана заплатили. Я бы на месте такого человека подумал бы: «В смысле мы хотели попробовать докер бл*дь? Максим нас на*бал что-ли с этим всем переходом?». Неудобно вышло бы, согласитесь.

Я нигде не упоминал что решение о миграции было потому что мы просто хотели. У нас был ряд задач, мы его решили. Все остались довольны. А люди, которые за это платили прочитали эту статью ещё до ее выхода)

Насправді більшість хочуть k8s чи docker не задаючись питанням а чи точно у проекті це доречно? Так само і з SOA чи взагалі мікро-сервісами — там де можна обійтись запросто грамотним монолітом, робиться комбайн-швейцарський-ніж тому що дуже хочеться побавитись з чимось новим. Правильний аргумент переїзду, «бо нам (девелоперам) так зручно і дуже хочеться», а решта раціоналізації вже підтягується по ходу як ось з навантаженням.

Ну, во-первых, моя статья никому ничего не должна)

А во-вторых, специально в статье указал что мотивация была исключительно личная, я никому не навязываю свое мнение, а просто рассказываю личные приоритеты и опыт.

Откройте docker.com и там вы найдете сугубо технические аспекты.

Складывается ощущение, что Вам в молодости запретили переехать на докер, и у вас образовался комплекс «CTO запретил», учитывая сколько раз Вы об этом упомянули в комментариях.

Психология точно не ваше ))
Вы публикуете техническую статью и выкладываете ее на обсуждение в техническом сообществе. А потом обижаетесь, что вам указывает на технические неточности и нелогичность некоторых утверждений. 🤷‍♂️

Если вы считаете что в статье есть технические неточности, так назовите как было бы точнее)

Я же говорю, с удовольствием выслушаю ваши предложения)
Я не услушал ни одного аргумента от Вас. Подкрепите свои слова аргементами)

Вы считаете что миграция была бессмысленной и как гуру айти вам не нравятся ее причины. Окей. Предложите решение вышеперечисленных проблем)

Как бы вы их решили? Расскажите)

Вы буквы вроде знаете, а читать не получается у вас. Перечитайте ещё раз то, о чем я вам писал. Там конкретно написано, что не так в статье.

И не нужно приписывать мне того, чего я не говорил. За ваши фантазии я отвественности не несу.

Вы так и не ответили где должен хоститься ELK. Расскажите раз уж упомянули его.

ELK может хостится где угодно.
Но судя по тому, какие вопросы вы задаёте, вы так и не поняли что не так в вашей таблице.

Перечитайте ещё раз постановку проблемы, как она написана у вас, затем подумайте, какую проблему решали на самом деле.

Ещё раз дам подсказку: проблема не в необходимости миграции. Проблема в аргументации. Поработайте над этим. Когда попадёте на серьёзный проект — вам это пригодится.

так вы опять не ответили)

И все же, если для вас эти аргументы в статье не подходящие, так предложите где должен крутиться ELK на нашем проекте)

Пожалуйста, не уходите от ответа)

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

Предложите решение, вы же архитектор.

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

Телепатирую, что вам нужны были EK без L. Но в любом случае зачем для этого мигрировать основное приложение? Как удобство запуска и администрирования сторонних приложений связано с миграцией основного приложения?

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

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

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

Вы так и не ответили где должен хоститься ELK. Расскажите раз уж упомянули его.

Я представляю, как вы задаете этот вопрос на собесе. Я бы молча встал и вышел, ей-Богу.

Этот вопрос был задан в контексте необоснованного высказывания Андрея. К чему ваш комментарий?

К чему ваш комментарий?

К комментарию вашему.

Підписатись на коментарі