Comments 40
с чего тогда чуствовать себя комфортнее?
github.com/Nyr/openvpn-install
Вот тоже просто, тоже без докера, одной командой: https://github.com/vmspike/openvpn-manage
Спасибо за скрипт!
Ага, запуск докера в privileged режиме — не лучшая идея. Сами разработчики говорят, что privileged существует только для особо экстраординарных задач, например как запуск докера внутри докера. Для всего прочего --cap-add, как у автора поста. Настаивать на то, что там внутри контейнера и ломать-то нечего можно сколько угодно, но это не докер вей.
Например, чтобы потом все убрать и не осталось "хвостов" в системе. Или чтобы ограничить vpn-сервис в ресурсах. Непонятно зачем docker-compose, разве что не вводить параметры каждый раз, но, ИМХО, проще sh-скрипт сваять
Например, я не практикую принцип "1 vps — 1 сервис". Т.е. на vps крутится обычно много мелких сервисов и openvpn (и ipsec+strongswan) находятся именно в докере, п.ч. это удобно — мне не надо вспоминать, что и как настраивается, мне надо просто на новую vps клонировать репу с Dockerfile, положить ключи и запустить скрипт, создающий контейнер. На вкус и цвет фломастеры разные — кому как удобнее. Лично мне глаз режет использование docker-compose для одного контейнера, но опять-таки — кому как удобнее.
docker-compose затем, что делает жизнь легче.
Чтобы переиспользовать много раз одну и ту же систему не настраивая ее. В данной статье, если вы обратили внимание, не идет речь о том, как настроить впн, а рассказывается как пользоваться поделкой автора. И когда автор обновит контейнер, вы не пойдете перенастраивать ваш впн, а сделаете docker pull.
Все ставиться и настраиваться этим скриптом https://github.com/StreisandEffect/streisand/blob/master/README-ru.md
Приватные сертификаты CA и клиентские не должны генерироваться и храниться на сервере. И было бы логичнее собрать образ со своими сертификатами и настройками, а не пробрасывать вовне каталог, который никто сколько-нибудь регулярно менять не обирается.
Я хоть и только начинаю знакомство с докером, но уже знаю, что имедж собраный как
FROM alpine:latest не то чтобы очень предусмотрительно. Сам напарывался на эти вилы, когда образ использует по умолчанию тег latest, а в последней версии того же alpine нужных зависимостей уже нет. Все таки лучше указывать конкретный тег.
Так же хотел отметить, что если используется SELinux(например, в Centos по дефлоту), то если не указать опции монтирования z или Z, то на запись из контейнера в директорию на хосте ничего работать не будет.
volumes:
- {path_to_save_openvpn_config}:/etc/openvpn:Z #если несколько контейнеров будут обращаться по одному маунту, то опция должна быть "z"И комментарий для всех, кто говорит можно проще. Да, можно проще, но с докером мы получаем нормальную переносимость окружения на любой дистрибутив любой версии(в рамках поддержки докера, конечно) без хитрых манипуляций. Можно ставить самую последнюю версию нужного ПО без страха поломать зависимости на работающем сервере, например. Или парой команд экспортировать хоть контейнер, хоть имедж, хоть вольюм в архив, и на новом сервере так же все это импортировать обратно.
Ну вот почему нельзя ему указать предел количества перезапусков, как это можно сделать в других правилах, ну что за бред…
Установка и настройка OpenVPN сервера с помощью docker-compose