Comments 40
2) Всегда думал что контейнер создается набором средств (namespace, cgroups, что там еще?) ядра linux (да, я знаю про WSLv1), а внутри контейнера просто юзерленд содержится.
Что бы не поседеть надо понимать суть вещей, я считаю.
Точно, кажется уже любой гайд по докеру начинается с "докер — не ВМ", и всё равно такое мнение берется откуда-то.
Плюс вредные советы вроде открытия контейнеров в сеть хоста, вместо создания отдельных docker network — одной для связи между фронтом и беком, и одной между беком и бд. В docker-compose это две строчки.
Собственно автор 2262288@gmail.com Ивент-агентство Арлекино и этим всё сказано
Пожалуйста не делайте так:
return await res.json();
Почему можно посмотреть тут:
1. Why Using `return await` Is a Bad Idea?
2. Disallows unnecessary return await (no-return-await)
Интересно, спасибо. То есть, мы обрабатываем Promice в том же методе и возвращаем только готовый ответ, дождавшись его?
const getResource = async () => {
const res = await fetch(JSON_URL);
return await res.json();
};И этот вариант:
const getResource1 = async () => {
const res = await fetch('https://api.zaycev.fm/api/v1/channels');
return res.json();
};
Вернут одинаковые результаты.
Однако результат асинхронной функции уже завернут в Promise.resolve (не явно). Т.о. в первой функции дополнительный await накладывает небольшой оверхед — по сути делается таже самая работа 2а раза.
Также, можно положить все приложения в один образ и развернуть как один контейнер.
Это плохая практика, так делать не надо… Зависнет у Вас клиент на NodeJs, а перезагружать придется и бек тоже, лишние ресурсы на запуск бэка (который не требовалось перезагружать вообще), создание для себя лишних трудностей (и героическое их преодоление) когда возникнет потребность в балансировке нагрузки, из-за жесткой связи — один экземпляр клиента к одному экземпляру сервера.
Я не специалист в NodeJs(вообще), объясните кто ни будь, зачем он в этой схеме, какую задачу он должен решать? Из этой схемы мне на ум приходит:
— Серверный рендеринг страниц
— Раз взаимодействие с бэком на java идет за ним, то это некий Gateway, значит он несет в себе еще и функционал валидации запросов и наверно аутентификацию этих запросов.
Я ни в коем случае не придираюсь, и осознаю, что это просто пример, но это не пример из практики и никто так делать скорее всего не будет (правда ведь не будет?), а значит такую статью сложно осмыслить для практического применения теми людьми для которых эта статья написана.
На протяжении своей профессиональной деятельности я не раз сталкивался с таким подходом, вот и сейчас мы пишем приложение на докере с полутора десятками микросервисов, которые собираются, правда, через OpenShift (но это уже другая история), но внутри тот же докер. Если говорить о хакатонах, то подход, когда каждый пишет свой микросервис, а потом всё это собирается отдельно и общается через REST — вообще, на мой взгляд, самый рабочий.
У современных веб-фреймворков существует такая фича, как SSR — рендер на стороне сервера. Он может использоваться для ускорения загрузки страницы, для поддержки браузеров без javascript и для снятия проблем индексации поисковиками.
Поскольку эта штука исполняет клиентский javascript на стороне сервера, ей конечно же нужен рантайм. Например, nodejs.
Кто к кому должен при этом обращаться с запросами (нода к бакенду или бакенд к ноде) — не принципиально, возможны оба варианта.
Почему же? Как раз для SPA серверный пререндер является стандартной оптимизацией.
рекомендую в данной задаче попробовать именно его — тогда и запускать будет легче, и сеть можно будет легко настроить
Я не специалист в контейнерах, но когда работал с Cloud Foundry ощутил все эти неудобства, когда приходилось прыгать между IDE, и поднимать то одно приложение локально, то другое, потом делать где-то изменения, потом подключаться к отладчикам, потом решал проблемы с CORS, если не подумал о них заранее… А в вашей статье (спасибо ещё раз), как-то всё просто. Вставили этот код, тот, запустили и всё работает.
Извините, но мне бы хотелось посмотреть на статью как разработчик организовывает свой рабочий процесс этого небольшого приложения. Вот это было бы интересно. Может быть у вас есть портянка скриптов для локальной разработки, о которой вы просто не сообщили :)
(ок,
ng serve --poll 2000 — просто запущен в другом терминале), а в докер кладутся уже бинари (и поднимаются для тестов\продакшена у амазона)
Все в Интелиджи поднимется. Npm start для фронта и зеленый треугольничек для бэка. А профиля, он поэтому все под хостовой сетью и запустил в докере, чтоб с профилями и портами не трахаццо, наверно.
Это не очень хороший совет. Фишка в том, что если каталог /host/directory не создан, то докер его создаст сам с правами от рута. Ну, и далее начинается вакханалия. В теории — лучше пользоваться расширенным синтаксисом bind mount и подготавливать каталоги самому с нужными правами.
Ну, или как вариант — использовать volume для данных.
Контейнер — это не виртуальная машина.
Дальше даже читать не хочется.
Примерно аналогичные чувства. Но за что дальше зацепился взгляд — так это за EXPOSE в докерфайле. Его суть абсолютно не раскрыта, а именно — как правило — это тупо аннотация, вроде документации. По факту же у него есть два применения (docker run -P и ещё что-то аналогичное), в остальном — на прохождение пакетов и доступность портов между сервисами не влияет
Запускать приложение в режиме разработки для продакшена это сильно.
P.s. для продакшена в CRA придумали npm run build
Спасибо за ваш опыт. Благодаря вам смог развернуть спринговый бэкэнд в докер, поскольку я новичек, мне было очень интересно и ваша статья помогла мне сделать это, не сильно утруждаясь.
Хотя здесь все пишут о недочётах, я считаю правильно пишут, но вообщем вы молодец .
Docker: как развернуть фуллстек-приложение и не поседеть