Комментарии 32
По долгу работы приходится иметь дело в VirtualBox на борту с Linux. Вы случайно не подскажите как можно автоматизировать создание снапшотов гостевой оси?
Virtualbox + Vagrant + ansible|chef|puppet
Смотрите в сторону команды VBoxManage
Как альтернатива, для изолированного рабочего окружения есть bitnami.
Не проще это будет через docker делать?
Возможно, знакомлюсь с ним
Также советую ознакомиться с Docker. Тем более если у вас хостовая машина на Linux.
Итак, плюсы:
1) Если изменения в контейнере не закоммитить то они не сохраняются — стало быть нет нужды в очистке мусора после работы с виртуалкой
2) Гибкая система с наслаиванием образов контейнеров друг на друга — есть возможность пилить минимально отличающиеся конфигурации на базе одного контейнера
3) Он просто работает быстрее и стартует практически моментально из-за отсутствия оверхеда на виртуализацию железа
Недавно решал для себя схожую задачу, получилось вот так: hamdeew.ru/page/lokalnyj-vebserver-bez-boli-s-docker
Также скидываю дамп БД при остановке контейнера и также годом ранее городил огород из костылей к VirtualBox =)
Итак, плюсы:
1) Если изменения в контейнере не закоммитить то они не сохраняются — стало быть нет нужды в очистке мусора после работы с виртуалкой
2) Гибкая система с наслаиванием образов контейнеров друг на друга — есть возможность пилить минимально отличающиеся конфигурации на базе одного контейнера
3) Он просто работает быстрее и стартует практически моментально из-за отсутствия оверхеда на виртуализацию железа
Недавно решал для себя схожую задачу, получилось вот так: hamdeew.ru/page/lokalnyj-vebserver-bez-boli-s-docker
Также скидываю дамп БД при остановке контейнера и также годом ранее городил огород из костылей к VirtualBox =)
да, еще раз спасибо за наводку на docker. я его уже поковырял немного и полностью согласен, что на нем это намного удобнее делать и пилю скрипты уже в сторону docker. в конце концов, он меньше ресурсов выедает. но есть несколько камней, которые я опишу, но сначала вопрос:
в процессе однакомления с docker я выкачал образ CentOS (в пачке я получил три образа: centos5, centos6, centos7 — остановился на шестом)
далее я запускаю контейнер и вижу следующее:
я что-то там установлю, сделаю в этом контейнере. выключу-включу его же незакоммиченный через start и вижу все то, что я устанавливал и изменял. это плохой тон использовать незакоммиченные контейнеры для работы? нужно для при очерезной потребности запускать (run) контейнер для работы с ним?.. хотя да, если мы пробрасываем в него разные проекты, то должны и перезапускать контейнер (stop, rm, run) с новым проектом. хотя, может, я до конца ещё не вникся философией docker
но все же мне хотелось бы иметь следующее:
итак, камни:
больше камней не припомню — не натолкнулся ещё
в будущем хотелось бы это все дело поднять именно на docker — меня соблазнила скорость его работы и легковесность
в процессе однакомления с docker я выкачал образ CentOS (в пачке я получил три образа: centos5, centos6, centos7 — остановился на шестом)
# docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
centos centos5 5a1ebaa356ff 5 days ago 484 MB
centos centos7 70214e5d0a90 9 days ago 224 MB
centos latest 70214e5d0a90 9 days ago 224 MB
centos centos6 68eb857ffb51 9 days ago 212.7 MB
далее я запускаю контейнер и вижу следующее:
# docker ps
CONTAINER ID IMAGE COMMAND ....
e8e254b40b74 centos:centos6 "/bin/bash" ....
я что-то там установлю, сделаю в этом контейнере. выключу-включу его же незакоммиченный через start и вижу все то, что я устанавливал и изменял. это плохой тон использовать незакоммиченные контейнеры для работы? нужно для при очерезной потребности запускать (run) контейнер для работы с ним?.. хотя да, если мы пробрасываем в него разные проекты, то должны и перезапускать контейнер (stop, rm, run) с новым проектом. хотя, может, я до конца ещё не вникся философией docker
но все же мне хотелось бы иметь следующее:
- Запустить контейнер (start)
- Выполнить скрипт с одним-двумя-тремя параметрометрами (папка с хост-машины прокидывается в docker, разворачивается БД)
- Работаем с проектом
- Выполнить скрипт с одним-двумя-тремя параметрометрами (БД дампится обратно и дизмаунтится папка)
итак, камни:
- Пока не встретил нигде возможности удаленно с хост-машины выполнить скрипт в контейнере (да, можно выполнять его при запуске контейнера (run), но пока не связал все в единый скрипт, чтобы его выполнить)
- Можно в контейнере поднимать sshd и с хост-машины выполняться скрипт в контейнере
# ssh root@container 'service httpd restart'
но мне кажется это неправильным идеологически в разрезе docker. К тому же, постоянно изменятся IP контейнера — как минимум, будет спрашивать прием server fingerprint — что тоже не особо удобно. Прописывать нужные IP и относить их к конкретному домену в dnsmasq.conf я уже научился.
больше камней не припомню — не натолкнулся ещё
в будущем хотелось бы это все дело поднять именно на docker — меня соблазнила скорость его работы и легковесность
По идее активно коммитить в контейнер не следует — это всего лишь окружение для запуска ваших проектов которое должно оставаться неизменным.
Вот краткий рецепт первоначальной настройки:
1) Делаем docker pull нужного образа (чтобы не скачивать всю линейку можно указать конкретный релиз)
2) Запускаем через docker run -t -i <image_name> /bin/bash и попадаем в консоль вашего контейнера.
3) Там все настраиваем как надо и затем запускаем второй терминал на хост машине, там набираем docker ps и в итоге получаем container_id, затем полученный id применяем вот так docker commit <container_id> <my_image_name>
4) В первом терминале просто выходим из контейнера по Ctrl+D, он автоматически останавливается.
Затем работаем вот так (привожу мой вариант):
1) Запускаем наш получившийся контейнер через docker run -v /home/rail/www/project/:/var/www/srv/ -p 80:80 -t -i rhamdeew/lamp /bin/bash
2) Там запускаем необходимые сервисы (для удобства bash-скриптом)
3) Кодим
4) Запускаем stop.sh и после окончания его работы выходим по Ctrl+D
Кстати посмотреть все доступные контейнеры на вашей машине можно так — docker ps -a
P.S. Совсем забыл — полученный в итоге готовый для работы контейнер можно сохраниить в репозитории hub.docker.com дабы иметь возможность оперативно его восстановить оттуда либо поделиться с друзьями.
Вот краткий рецепт первоначальной настройки:
1) Делаем docker pull нужного образа (чтобы не скачивать всю линейку можно указать конкретный релиз)
2) Запускаем через docker run -t -i <image_name> /bin/bash и попадаем в консоль вашего контейнера.
3) Там все настраиваем как надо и затем запускаем второй терминал на хост машине, там набираем docker ps и в итоге получаем container_id, затем полученный id применяем вот так docker commit <container_id> <my_image_name>
4) В первом терминале просто выходим из контейнера по Ctrl+D, он автоматически останавливается.
Затем работаем вот так (привожу мой вариант):
1) Запускаем наш получившийся контейнер через docker run -v /home/rail/www/project/:/var/www/srv/ -p 80:80 -t -i rhamdeew/lamp /bin/bash
2) Там запускаем необходимые сервисы (для удобства bash-скриптом)
3) Кодим
4) Запускаем stop.sh и после окончания его работы выходим по Ctrl+D
Кстати посмотреть все доступные контейнеры на вашей машине можно так — docker ps -a
P.S. Совсем забыл — полученный в итоге готовый для работы контейнер можно сохраниить в репозитории hub.docker.com дабы иметь возможность оперативно его восстановить оттуда либо поделиться с друзьями.
спасибо за подсказки и информацию
я поковырял ваш контейнер, ваши скрипты start/stop и разобрался как у вас оно работает. на сколько я понял, то вы пробрасываете папку проекта в контейнер (-v). я только вот не совсем разобрался как вы решили следующую проблему: папку с расшариваю (-v /path/to/src:/path/to/dst), но апач, запущенный под apache:apache не может использовать и писать в файлы, которые были расшарены в контейнер. Владелец и группа папки/файлов — 1000. на сколько я понимаю, то это UID и GID с хост-машины. Далее, если я изменю владельца: группу на файлы с контейнера, то изменятся эти данные и в на хост-машине, но на UID:GID пользователя с контейнера.
Можно ли это как-либо причесать чтобы при расшаривании в контейнере файлы принадлежали определенному пользователю (например, апачу для удобной работы с ними) и новые файлы, залитые в контейнер посредством апача (аплоад файла например) на хост машине принадлежали текущему пользователю на хост-машине?
разбираюсь и приходят новые мысли как мне это все расширить и реализовать
я поковырял ваш контейнер, ваши скрипты start/stop и разобрался как у вас оно работает. на сколько я понял, то вы пробрасываете папку проекта в контейнер (-v). я только вот не совсем разобрался как вы решили следующую проблему: папку с расшариваю (-v /path/to/src:/path/to/dst), но апач, запущенный под apache:apache не может использовать и писать в файлы, которые были расшарены в контейнер. Владелец и группа папки/файлов — 1000. на сколько я понимаю, то это UID и GID с хост-машины. Далее, если я изменю владельца: группу на файлы с контейнера, то изменятся эти данные и в на хост-машине, но на UID:GID пользователя с контейнера.
Можно ли это как-либо причесать чтобы при расшаривании в контейнере файлы принадлежали определенному пользователю (например, апачу для удобной работы с ними) и новые файлы, залитые в контейнер посредством апача (аплоад файла например) на хост машине принадлежали текущему пользователю на хост-машине?
разбираюсь и приходят новые мысли как мне это все расширить и реализовать
Проблему с правами доступа решил не самым элегантным путем, но это все же не продакшн. Так что думаю можно =)
1) Создал в контейнере такого же обыкновенного пользователя useradd rail и его UID/GUID также стали равны 1000
2) Подправил запуск Apache под этим пользователем vim /etc/apache2/envvars, там параметры APACHE_RUN_USER и APACHE_RUN_GROUP выставил rail
Вот собственно и все =)
1) Создал в контейнере такого же обыкновенного пользователя useradd rail и его UID/GUID также стали равны 1000
2) Подправил запуск Apache под этим пользователем vim /etc/apache2/envvars, там параметры APACHE_RUN_USER и APACHE_RUN_GROUP выставил rail
Вот собственно и все =)
Дополню, что можно дать имя контейнеру и не надо будет колдовать с id`ишникам, плюсом будет возможность связывать контейнеры между собой и обращаться по именам контейнеров внутри контейнеров.
Все очень красиво, можно даже использовать…
Только немножко упростить.
1. Создать локальную сеть из виртуальной машины (или из машин).
2. Соответственно настроить hosts на свои develop сайты (из виртуальной машины).
3. Использовать sshfs
В заключение — правильно настроить сервер на виртуалке для быстрого разворачивания любого сайта, а не издеваться над /var/www
Только немножко упростить.
1. Создать локальную сеть из виртуальной машины (или из машин).
2. Соответственно настроить hosts на свои develop сайты (из виртуальной машины).
3. Использовать sshfs
В заключение — правильно настроить сервер на виртуалке для быстрого разворачивания любого сайта, а не издеваться над /var/www
mkdir -p /root/bin— вообще умиляет…
- Подразумевается, что локальная сеть с виртуальной машиной есть. Используется HostOnly виртуальная сетевая карта и через неё осуществляется доступ с основной машины (ноут) к виртуальной — в данном случае сеть 192.168.191.0/24. Это должно быть понятно ибо в любом случае нужно как-то к гостевой машине по ssh, http и/или использования удаленной работы с mysql сервером
- Я так понимаю, что Вы предлагаете иметь доступ с виртуальной машины на продакшн-хост сайта? Для чего? Деплой можно реализовать с машины, где ведется разработка (я не знаю как правильно её назвать в этом контексте — ноут). PhpStorm позволяет синхронизацию с удаленным сервером, выгрузку измененных файло после успешного коммита изменений в git, можно настроить деплой через хуки гита — деплой можно придумать какой-угодно. Я не вижу упрощения в данном случае
- Упросить путем использования sshfs? Если я Вас верно пониаю, то вы предлагаете с виртуальной машины стучаться в ноут, брать там нужную папочку и монтировать её по sshfs в вирутальную машину? Если верно, то нам придется под каждую папку руцями прописывать путь к требуемой папке. Папки проектов могут лежать на ноуте где-попало — нам ничего не запрещает один проект положить на декстопе, второй в /tmp, третий в ~/Downloads и так далее. Есть ли идея реализации универсального монтирования этих папочек в виртуальную машину? Мне в голову пока ничего не приходит. В моем случае все монтируемые папки лежат в одном месте /media/sf_*. Изначально я выбирал непустые папки из этой директории и монтировал. Но потом использовал непосредственно список подмонтированных папок, что я считаю более правильным. В таком случае нам вообще не нужно лгиниться в виртуальную машину чтобы настроить монтирование нужной папки. Мы просто кладем конфиг для веб-сервера в папку проекта, расшариваем папку в виртуальную машину и запускаем ей. Все! Больше мы ничего не делаем.
- Как правильно настроить сервер, я думаю, что имеемтся в виду веб-сервер, для быстрого разворачивания любого сайта? DocumentRoot может быть как в корне, так и в директории www/, могут быть специальные настройки окружения (на некоторых проектах я использую настройку через SetEnv для статуса приложения: дебаг или нет. Я считаю, что это удобно сделать в настройках виртуального хоста веб-сервера для каждого проета.
- Чем
# mkdir -p /root/bin
не угодил? после установки этой папки у рута дома нет. А может у кого и есть. В используемом мной дистрибутиве её не было.
Целью ставилось создание независимого скрипта, который бы дела все за нас, а от нас требовалось бы только подготовить конфиг для веб-сервера и положить дамп базы если это нужно.
Вы используете автоматически подключенные папки. В скрипте вынуждены их же искать, чтобы потом их еще раз примонтировать.
Блок схема этой логики выглядела бы как минимум странно и неэффективно.
Куда проще было бы работать с заранее известным расположением «папочек» и «файликов», использовав для этого например nfs.
PS.
Хостнейм у гостевой машины должен иметь вид домена, и называется это FQDN.
Блок схема этой логики выглядела бы как минимум странно и неэффективно.
Куда проще было бы работать с заранее известным расположением «папочек» и «файликов», использовав для этого например nfs.
PS.
Хостнейм у гостевой машины должен иметь вид домена, и называется это FQDN.
Да, можно было бы использовать, но как я писал выше, это было бы не настолько юзабельно и пришлось бы вручную прописывать путь для каждого проекта (папки)
За FQDN спасибо
За FQDN спасибо
статью подробно не читал, но вроде как vagrant то же самое делает?
Если хост система основана на Linux, то лучше использовать docker. Как минимум не будет затрат на еще одну работающую ОС. Как максимум, можно будет поднимать докер контейнеры на сервере, гарантировав однообразность окружения продакшена и двелопминга.
1. ok, невнимательно посмотрел
2 и 3. Я имел ввиду, что раз уж вы на VM разработку делаете, то все там же и лежит. Поэтому sshfs. Кстати, «стучаться» при соответствующей настройке совсем нет надобности.
Если же монтировать папки с ноута в VM, то, если я правильно помню, VM имеет стандартные средства совместного использования папок с автомонтированием.
PHPStorm не использую. Пользуюсь Sublime.
И, в заключение, я так понял, все это в контексте Windows?
Для себя давно сделал выводы и использую на компьютерах Linux, уже давно.
Там этих проблем нет.
На ноуте стоит lighttpd, я его и в работе использую.
С остальными компонентами — Mysql, Redis, git, тоже проблем нет :) Плюс любая автоматизация :)
В результате старт проекта — создание хоста -> инициализация проекта (git bitbucket)
Поэтому практически отпала необходимость в VM при разработке.
VM только, если что-то хочется попробовать неординарное, или смоделировать сеть.
По-поводу /root/bin — есть стандартная организация файловой системы. И для ваших целей есть каталог /usr/local/bin
2 и 3. Я имел ввиду, что раз уж вы на VM разработку делаете, то все там же и лежит. Поэтому sshfs. Кстати, «стучаться» при соответствующей настройке совсем нет надобности.
Если же монтировать папки с ноута в VM, то, если я правильно помню, VM имеет стандартные средства совместного использования папок с автомонтированием.
PHPStorm не использую. Пользуюсь Sublime.
И, в заключение, я так понял, все это в контексте Windows?
Для себя давно сделал выводы и использую на компьютерах Linux, уже давно.
Там этих проблем нет.
На ноуте стоит lighttpd, я его и в работе использую.
С остальными компонентами — Mysql, Redis, git, тоже проблем нет :) Плюс любая автоматизация :)
В результате старт проекта — создание хоста -> инициализация проекта (git bitbucket)
Поэтому практически отпала необходимость в VM при разработке.
VM только, если что-то хочется попробовать неординарное, или смоделировать сеть.
По-поводу /root/bin — есть стандартная организация файловой системы. И для ваших целей есть каталог /usr/local/bin
Хост-машина тоже под Linux, но проблема в версиях ПО, прежде всего PHP. Изначально это делалось для того, чтобы иметь возможность разрабатывать на разных версиях PHP. Есть проект, который жестко требует php5.3 и переписывать его, как минимум, на php5.4 никто точно не будет, а допиливать его нужно. Остальные проекты требуют, как минимум, php5.4. php5.4 для тестирования и php5.6 для ознакомления. Поднять этот весь зоопарк на одной машине, на хосте, и настроить динамическую смену версий для каждого проекта и к тому же, чтобы одновременно один и тот же проект запустить на нескольких версиях php невозможно. Да, несколько версий php можно поднять и настроить, но это ещё те танцы с бубном. Лично мне не хочется загаживать рабочую ОС (да тот же Linux) левым софтом типа четырех версий php, установленным с танцами.
В качестве удаленного репозитория я использую связку Redmine+Gitolite на удаленном сервере.
В качестве удаленного репозитория я использую связку Redmine+Gitolite на удаленном сервере.
Расскажите автору про Docker %-)
не знаю где тут лень, с vagrant все значительно проще )))
Vagrant у меня не завелся с конфигом от puphpet.com — валился httpd и ни в какую
советую пройти их мануал на офф-сайте — docs.vagrantup.com/v2/getting-started/index.html. Классная вещь.
У меня тоже пару раз их конфиг валился. Но в итоге все равно в большинстве случаев все загружалось без сбоев. Можно еще разок попробовать )
Добавлю, что часто для рабочих групп единая среда — суровая необходимость. А чтобы компенсировать тормоза виртуалки, ставьте ее на SSD. С ним даже Windows-кластер из двух виртуальных машин летает. И ядер побольше отдайте. Будете приятно удивлены, видя на что способен ваш компьютер…
Когда мне надоело сидеть на общих девсредах на рабочем сервере с одной базой на всех и другими разделяемыми ресурсами, я создал полноценный инстанс в виртуалке под виртуалбоксом. Скриптом запускаю виртуалку, тут же монтирование папки в хостовую ОС для работы под эклипсом (виртуальная девреда для экономии ресурсов без гуя), и шел. Аналогичный скрипт закрытия. Гемор был с подъемом всех частей веб-приложения на одной виртуальной машине. В реальном инстансе разные роли разделяются на разные машины: приходилось вникать и решать конфликты. Но в итоге решение получилось: полностью автономная работа даже без интернета, при необходимости (или с медленным интернетом, при котором крайне некомфортно работать по сети из-за большого пинга). До сих пор отлично работается удаленно и независимо от инфраструктуры работодателя (особенно после перехода на гит).
Я видимо совсем ленивый, мне Wampserver-a достаточно
кто-нибудь подскажет как решить проблему с docker?
как вариант — не запуска
- запускаю контейнер с
--privileged— в контейнере не запускается mysql-server
результатroot@b1d8a93c420a:/# service mysql start /usr/sbin/mysqld: error while loading shared libraries: libaio.so.1: cannot open shared object file: Permission denied
- запускаю контейнер без
--privileged— не работает sshfs
результатroot@5d61518c125f:/# sshfs dvapelnik@172.17.42.1:/home/dvapelnik/tmp /mnt -o uid=33,gid=33 fuse: failed to open /dev/fuse: Operation not permitted
sshfs нужен для корректного монтирования папки с хост-машины — при прокидывании папки с помощью run -v не совсем корректно идет работа с правами на содержимое этой папкикак вариант — не запуска
mysql-server в контейнере, а использовать mysq-server на хост-машине, но тогда для прозрачности работы с ним через localhost было бы неплохо сфорвардить порт 3306 с контейнера в хост-машину, а это не удается
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Лень — двигатель прогресса или мой вариант создания окружения для веб-разработки на основе VirtualBox