Безопасность подразумевает необходимость ежедневных обновлений пакетов ОС, из-за чего почти каждый день необходимо будет пересобирать как базовый образ, так и часть образов с приложениями (если они содержат какие-то дополнительные пакеты ОС помимо самого микросервиса).
Поэтому я и выступаю за использование Alpine образа в качестве базового — там всего 4 пакета, которые обновляются достаточно редко (уж никак не каждый день). Однако, musl libc приносит как свои плюсы, так и свои грабли… Я не вникал в hardened gcc, но пакеты в Alpine Linux собраны с stack-smashing protection.
В общем, если у вас уже есть отлаженная схема, то я не вижу смысла её ломать просто для того чтобы ввернуть где-нибудь Docker. Однако, я уже год гоняю в продакшене 15 образов основанных на Alpine Linux, суммарным объёмом в 4ГБ и как-то вопрос пересборки меня вообще никогда не напрягал (да, Rust и Haskell из исходников пересобираются долго, но этим занятием занимается машина и не больше одного раза в неделю, так что для меня это не является критичным процессом, да и то, когда появятся пакеты в Alpine Linux — жизнь станет веселее). Ну и использую я возможности ограничений ресурсов Docker контейнеров на полную, так что без Docker я бы даже, наверно, не приступил бы ещё к написанию этого проекта, а застрял бы в дебрях LXC.
Лукавите здесь Вы. Да, по умолчанию всё именно так. Но я в своём комментарии отвечал на конкретную статью, где автор рассказывал как докер радостно создаёт сети между датацентрами так, что контейнеры этого даже не замечают, и управляет всем этим хозяйством с одной машины — через какие конкретно UNIX-сокеты, по-вашему, всё это может работать?
Да, можно открыть доступ к Docker демону по сети, да, там можно настроить псевдобезопасность, и, наконец, ДА, мне это совершенно не нравится! Тут действительно можно долго познавать глубину дыры. Однако, есть другой подход — агенты, крутящиеся на сервере с Docker-daemon'ами, которые поднимают свою VPN до мастер ноды и общаются с локальными Docker-daemon'ами через UNIX-socket. Так делает как минимум Rancher и есть у меня подозрения, что так же (ну может без VPN) делают и Kubernetes, и Fleet, ну и остальные здравые люди.
То есть вы ожидали появления возможности запуска ELF исполняемых файлов на винде без виртуалок да ещё и сразу в контейнерах с контролем ресурсов? Line (по аналогии с Wine)? Грандиозная идея :)
Что-то у вас тёплое с мягким сравнивается и делается вывод об упругости...
Давайте начнём с развёртывания (почему-то вы начали за безопасность, но я вообще не понял как вы её там подразумевали). Docker образы состояти из слоёв, если у вас есть 25 приложений на Python и 25 приложений на Java, то вам нужен 1 образ базовой системы (лично я предпочитаю Alpine Linux — 5Мб), поверх этого образа будут установлены слои для Python, общие для 25 приложений на Python, и отдельная ветка будет идти с Java окружением, а дальше будут создаваться уже слои с приложениями. Таким образом, если обновилось только 1 приложение, и его образ обновится, то серверу при обновлении нужно будет скачать всего-навсего слои с самим приложением. Подведём итог в цифрах, пусть базовая система будет Alpine Linux — 5Мб, Python слои — 50Мб, Java слои — 160Мб, а каждое приложение будет занимать по 20Мб. При обновлении одного приложения вам нужно будет пересобрать слои самого приложения и серверу нужно будет скачать 20Мб (даже меньше из-за того что слои хранятся архивами), при обновлении Python нужно пересобирать 25 образов — 50Мб + 20Мб * 25, при обновлении Java — 160Мб + 20Мб * 25, а при обновлении базового образа, да все обзразы нужно пересобрать — 5Мб + (50Мб + 20Мб * 25) + (160Мб + 20Мб * 25), но если хотите заморочиться и вы хотите сделать отдельный случай "обновления системы" без полной пересборки, когда вы знаете, что пересборка не нужна (ну, например, обновилась только динамическая библиотека), то можно такие патчи наклвадывать сверху приложений, тогда при обновлении libopenssl.so серверам нужно будет скачать слой с новой openssl.so, добавленной последним слоем в каждый образ, 50 раз.
И это я ещё оставил за кадром вопрос небезопасности самого докера — а ведь это сервис, который работает под root, активно меняет настройки всей системы (так что бессмысленно даже пытаться SeLinux-ом или другой RBAC обрезать его права до необходимого минимума как принято делать для всех остальных рутовых сервисов), доступен по сети и из контейнеров, и при этом очень активно допиливается (в отличие от большинства других рутовых сервисов).
Да, сама идея root-демона, который занимается неизвестно чем — не самая приятная для осознания. Однако, стоит отметить, что вы лукавите здесь, говоря, что он доступен по сети и из контейнеров. По умолчанию, docker-daemon использует UNIX-сокеты, так что доступен он только локальным пользователям у которых есть права на доступ к сокету (обычно нужно находиться в группе docker).
Автор комментария скорее всего комментировал ваше "и уже в винде, не?". В общем, повторю — docker-daemon для Windows нет и не уверен будет ли вообще (хотя какая-то партнёрская программа у них с Microsoft наладилась уже давненько, может и пилят что-то под капотом), вот что сделали для Windows, так это собрали клиент docker-cli (aka docker), так что просто из Windows можно управлять удалёнными docker-daemon'ами (ну и docker-swarm'ами).
Я очень долго жил на bash и только в прошлом году решил снова поэкспериментировать с этими новомодными окружениями. zsh решил пропустить, а начал с xonsh, так как казалось, что это может быть удобно. В общем, не ужился я с ним из-за странностей (автодополнение мне всё время мешало понять что же я пишу) и отсутствия достаточно базовых вещей вроде && и || в bash, ну и поддержка virtualenv кривая (и это в shell'e на Python для любителей писать проекты на Python). А вот fish — действительно оказался очень приятной штукой, тут и остановился (даже небольшой скринкаст записал).
Я так понял, что автор хотел сказать, что данные в функцию appendLine у вас передаются через аргументы (appendLine "один" "два"), а он предлагает передавать через переменные окружения (header1="одиин" header2="два" appendLine), а в вашем случае можно их из глобальных переменных вообще читать, но это не очень красиво будет выглядеть.
P.S. Я не знаю какие накладные расходы у передачи через аргументы по сравнению с передачей через переменные окружения, я только перефразировал с примерами то, как я понял слова автора.
Спасибо за помощь в осознании ошибки, которая привела к негативу.
Смысл моего комментария был в том, что мне действительно было интересно прочитать о том, как можно собрать proxy с модификациями пакетов на лету «на коленке», да ещё и все утилиты есть в OpenWrt прошивке роутера.
Остальной текст был неудачным...
Намёк был на то, что меры будут ужесточаться и, если посмотреть на Китай, эта гонка может закончиться не в пользу граждан. «Когда они пришли...»
Ещё раз спасибо, я всё понял и дальше зарываться в политику у меня желания нет.
Хмм, я не хотел никому на мозоль наступать (простите, я просто об этом не подумал), как и не хотел злорадствовать (надеюсь хоть это у меня получилось передать), наоборот, я надеюсь увидеть победу здравого смысла (нет, я не надеюсь на политиков уже давно и не только в РФ) в такой-то большой стране!
Я с удовольствием прочитал бы пару критических тезисов относительно моего набирающего популярность комментария (-14 у комментария против всего +10 у самой статьи). Вам нравятся блокировки, которые (как мне опять же кажется) никто из здравомыслящих граждан не заказывал? Так тогда странно, что вы читаете эту статью вовсе. Мне любопытно: кто вы?
echo -ne "$header1\r\n"
# ждем секунду, чтобы netcat отправил пакет, если кто подскажет, как сделать это иначе — скажу спасибо
Возможно, проблема в stdin буфере netcat'a. Можно бы попробовать отключить буферизацию, но я знаю только одну утилиту для этого — stdbuf -i0, но я сомневаюсь, что она будет в прошивке роутера.
Мне данный пост интересен лишь с технической точки зрения (мне посчастливилось не быть гражданином такой страны как у Вас). Спасибо за интересную статью! Однако, в контексте вашего применения — это лечение побочных эфектов и, как мне кажется, решать проблему нужно в другом месте (но это я так, гипотетически).
Он, также как и Atom, основывается на движке Chromium
Интересная фраза, в духе жёлтой прессы. Atom использует модульную архитектуру, одной из частей которых является Electron (aka Atom Shell), и VS Code использует Electron, читай «движок Atom». А то у Вас получилось, что MS вдруг решила другой редактор написать, когда на деле они свой «мод» сделали (да, немаленький «мод», но и не трогали они непосредственно Chromium).
Даже в ООП вы не полезете в данные объекта за информацией о том что разршено делать с объектом, а спросите об этом у модуля безопасности, который, конечно, уже сам может решить проинспектировать запрашиваемый объект. Такой «модуль безопасности» в терминах RESTful API, как мне кажется, принято реализовывать по HTTP-запросу OPTIONS.
К сожалению, я не очень прямо в теме e-mail'ов, так что про признаки аутентификации судить не могу, но на gmail письма доходили без проблем, только приходит не само письмо на gmail, а ссылка на protonmail для прочтения с паролем, который нужно тогда передать получателю другим каналом.
Я попросил инвайт достаточно давно и давно его получил. Попробовал в своё время, но я не страдаю излишней паранойей (практикую умеренную паранойю), поэтому не остался у них, мне gmail хватает. У них вполне себе приятный интерфейс, тестовые письма уходили и приходили без проблем, не знаю что ещё добавить. Есть какие-то конкретные вопросы?
P.S. Прошу прощения на неверное название ссылки (ProtonMail.com, а не Photon, но в теге я правильную ссылку вставил, так что можно кликать)
Сложно? Да, чуть сложнее, чем решение в лоб, зато расширяемо. Не нравится RFC — напишите свою, но реализация «мне так нравится» подходит для своего личного пользования, а для фреймворка — это минус. OpenAPI (Swagger) спецификацией можно описать любой каприз и после этого у вас будет и интерактивная документация, и автогенерируемые клиенты на куче языков, но Eve не пошёл путём интеграции с Swagger, так что да, написать сервер просто, но потом клиента к нему писать придётся самому и работать с особенностями Eve на клиенте — тоже.
Опять же, можете у меня в примере посмотреть и как это выглядит в Swagger документации (Docker образ поднимается за полминуты), и в коде (я пока не оформил этот случай в отдельную обёртку, но думаю об этом), и в:
OpenAPI (Swagger) Specification JSON, который автоматически собирается Flask-RESTplus
"patch": {
"description": "**PERMISSIONS: Owner/Supervisor/Admin may execute this action.**",
"operationId": "patch_team_by_id",
"parameters": [
{
"in": "path",
"name": "team_id",
"required": true,
"type": "integer"
},
{
"in": "body",
"name": "body",
"required": true,
"schema": {
"items": {
"properties": {
"op": {
"enum": [
"add",
"test",
"remove",
"replace"
],
"location": "json",
"type": "string"
},
"path": {
"enum": [
"/title"
],
"location": "json",
"type": "string"
},
"value": {
"location": "json",
"type": "string"
}
},
"required": [
"op",
"path"
]
},
"location": "json",
"type": "array"
}
}
],
"responses": {
"200": {
"description": "Success",
"schema": {
"$ref": "#/definitions/DetailedTeamSchema"
}
},
"401": {
"description": "Authentication with teams:write scope(s) is required",
"schema": {
"$ref": "#/definitions/401HTTPErrorSchema"
}
},
"403": {
"description": "Owner/Supervisor/Admin may execute this action.",
"schema": {
"$ref": "#/definitions/403HTTPErrorSchema"
}
},
"404": {
"description": "Team not found.",
"schema": {
"$ref": "#/definitions/404HTTPErrorSchema"
}
},
"409": {
"description": "A conflict happened while processing the request. The resource might have been modified while the request was being processed.",
"schema": {
"$ref": "#/definitions/409HTTPErrorSchema"
}
},
"422": {
"description": "The request was well-formed but was unable to be followed due to semantic errors.",
"schema": {
"$ref": "#/definitions/422HTTPErrorSchema"
}
}
},
"security": [
{
"oauth2": [
"teams:write"
]
}
],
"summary": "Patch team details by ID",
"tags": [
"teams"
]
}
Таким образом ответ нельзя закешировать, так как для разных пользователей будут отсутствовать некоторые ссылки, да и даже для одного пользователя нельзя закешировать — вдруг ему права урезали/добавили — инвалидировать кеш запаришься. Да и вообще, как по мне, то мухи должны быть отдельны от котлет. Хотите узнать какие действия можно производить над объектами — спросите об этом отдельно. Объект — это объект, а действия над ним — это отдельная история.
В общем, если у вас уже есть отлаженная схема, то я не вижу смысла её ломать просто для того чтобы ввернуть где-нибудь Docker. Однако, я уже год гоняю в продакшене 15 образов основанных на Alpine Linux, суммарным объёмом в 4ГБ и как-то вопрос пересборки меня вообще никогда не напрягал (да, Rust и Haskell из исходников пересобираются долго, но этим занятием занимается машина и не больше одного раза в неделю, так что для меня это не является критичным процессом, да и то, когда появятся пакеты в Alpine Linux — жизнь станет веселее). Ну и использую я возможности ограничений ресурсов Docker контейнеров на полную, так что без Docker я бы даже, наверно, не приступил бы ещё к написанию этого проекта, а застрял бы в дебрях LXC.
Да, можно открыть доступ к Docker демону по сети, да, там можно настроить псевдобезопасность, и, наконец, ДА, мне это совершенно не нравится! Тут действительно можно долго познавать глубину дыры. Однако, есть другой подход — агенты, крутящиеся на сервере с Docker-daemon'ами, которые поднимают свою VPN до мастер ноды и общаются с локальными Docker-daemon'ами через UNIX-socket. Так делает как минимум Rancher и есть у меня подозрения, что так же (ну может без VPN) делают и Kubernetes, и Fleet, ну и остальные здравые люди.
Давайте начнём с развёртывания (почему-то вы начали за безопасность, но я вообще не понял как вы её там подразумевали). Docker образы состояти из слоёв, если у вас есть 25 приложений на Python и 25 приложений на Java, то вам нужен 1 образ базовой системы (лично я предпочитаю Alpine Linux — 5Мб), поверх этого образа будут установлены слои для Python, общие для 25 приложений на Python, и отдельная ветка будет идти с Java окружением, а дальше будут создаваться уже слои с приложениями. Таким образом, если обновилось только 1 приложение, и его образ обновится, то серверу при обновлении нужно будет скачать всего-навсего слои с самим приложением. Подведём итог в цифрах, пусть базовая система будет Alpine Linux — 5Мб, Python слои — 50Мб, Java слои — 160Мб, а каждое приложение будет занимать по 20Мб. При обновлении одного приложения вам нужно будет пересобрать слои самого приложения и серверу нужно будет скачать 20Мб (даже меньше из-за того что слои хранятся архивами), при обновлении Python нужно пересобирать 25 образов —
50Мб + 20Мб * 25, при обновлении Java —160Мб + 20Мб * 25, а при обновлении базового образа, да все обзразы нужно пересобрать —5Мб + (50Мб + 20Мб * 25) + (160Мб + 20Мб * 25), но если хотите заморочиться и вы хотите сделать отдельный случай "обновления системы" без полной пересборки, когда вы знаете, что пересборка не нужна (ну, например, обновилась только динамическая библиотека), то можно такие патчи наклвадывать сверху приложений, тогда при обновлении libopenssl.so серверам нужно будет скачать слой с новой openssl.so, добавленной последним слоем в каждый образ, 50 раз.Да, сама идея root-демона, который занимается неизвестно чем — не самая приятная для осознания. Однако, стоит отметить, что вы лукавите здесь, говоря, что он доступен по сети и из контейнеров. По умолчанию, docker-daemon использует UNIX-сокеты, так что доступен он только локальным пользователям у которых есть права на доступ к сокету (обычно нужно находиться в группе docker).
&&и||в bash, ну и поддержка virtualenv кривая (и это в shell'e на Python для любителей писать проекты на Python). А вот fish — действительно оказался очень приятной штукой, тут и остановился (даже небольшой скринкаст записал).appendLine "один" "два"), а он предлагает передавать через переменные окружения (header1="одиин" header2="два" appendLine), а в вашем случае можно их из глобальных переменных вообще читать, но это не очень красиво будет выглядеть.P.S. Я не знаю какие накладные расходы у передачи через аргументы по сравнению с передачей через переменные окружения, я только перефразировал с примерами то, как я понял слова автора.
Смысл моего комментария был в том, что мне действительно было интересно прочитать о том, как можно собрать proxy с модификациями пакетов на лету «на коленке», да ещё и все утилиты есть в OpenWrt прошивке роутера.
Ещё раз спасибо, я всё понял и дальше зарываться в политику у меня желания нет.
stdbuf -i0, но я сомневаюсь, что она будет в прошивке роутера.habrahabr.ru/post/271197
habrahabr.ru/post/271361
Кстати, при отправке я указал пароль «habrahabr» и время жизни сообщения 1 неделю.
P.S. Прошу прощения на неверное название ссылки (ProtonMail.com, а не Photon, но в теге я правильную ссылку вставил, так что можно кликать)
Опять же, можете у меня в примере посмотреть и как это выглядит в Swagger документации (Docker образ поднимается за полминуты), и в коде (я пока не оформил этот случай в отдельную обёртку, но думаю об этом), и в: