Docker в браузере, или как создать и «расшарить» среду разработки

    Docker нынче не использует только ленивый. Вокруг этой технологии заварилась очень интересная каша, не в последнюю очередь благодаря технологиям и продуктам, интегрировавшим Docker, который стал частью их инфраструктуры. Раннеры на Docker-е — это уже чуть ли не “must” для облачных IDE. Что уж говорить, если Google однозначно признали преимущества запуска приложений в контейнерах, а не на “чистом железе”. Впрочем, это тема другой дискуссии.

    Создание среды разработки в браузере

    Итак, Docker, скорее всего, изменит лицо технологического мира. Вернее, он уже его меняет. Все мало-мальски активные компании уже выложили свои докер образы, в которых запускаются их продукты. Ни тебе настройки среды, ни установки переменных окружения… Скачал образ, примонтировал локальные ресурсы, если нужно (“сорцы” проекта, локальный репозиторий и так далее), и горя не знаешь.

    Лидер рынка обычных IDE пошел немного дальше в вопросе использования Docker. Компания поставила себе 2 условия:

    • никаких скачиваний, установок и сопутствующих хлопот
    • пользователь ничем не ограничен в процессе “постройки” образа среды разработки


    Другими словами, чтобы создать среду разработки, нужен всего лишь браузер и учетная запись в Codenvy. По-порядку обо всем.

    Ранее, мы уже писали про облачные IDE, их преимущества и недостатки. Одним из главных недостатков была невозможность “кастомизации” окружения. Другими словами, у пользователя нет доступа к среде, где собирается и запускается его проект. Этот недостаток был учтен.

    Что же получает пользователь Codenvy? Получает он доступ к инстансу раннера, на котором установлен Docker. Конечно, доступ этот ограничен несколькими Docker командами, которые выполняются не явно, а через кнопки и меню веб-интерфейса. Пользователь может самостоятельно написать Dockerfile и нажать кнопку Run. По факту выполнятся 2 команды — docker build, и после успешного создания имиджа — docker run. Само собой, с набором параметров.

    Конечно же, предлагаются и предустановленные раннеры — их более 20. Но, если по каким-то причинам, дефотный раннер не подходит, существует более 1 решение:

    • “расширять” существующую среду. Другими словами, наследовать базовый имидж
    • создавать собственную среду “с нуля”. DockerHub предлагает тысячи имиджей, в том числе, официальных


    В итоге пользователь получает CodeMirror редактор со всеми соответствующим функционалом (подсветка синтаксиса, code folding, поиск, мультикурсор, автозамена), систему контроля версий Git, интеграцию с GitHub (используется oAuth. Для других git hosting провайдеров используется «ручное» SSH соединение), Datasource плагин для удобного подключения к базам данных и работу с ними (SQL редактор с автокомплитом и подсветкой синтаксиса).

    В имидж можно добавлять как “сорцы” проекта, так и “билд-артефакты”, jar, war, apk etc. Билд проектов может проистекать как нативно на отдельном инстансе (на данный момент поддерживаются Maven и Ant), так и непосредственно в “рантайме” — в таком случае нет ограничений по использовании билд системы — Grails, Gradle, Leiningen — все это без проблем устанавливается на линуксовую ось (рекомендуется легковесная Debian Jessie). Так, например, чтобы установить Maven в своей Codenvy среде, нужно выполнить нехитрые действия, мало чем отличающиеся от local experience:

    RUN mkdir /home/user/maven3 && \
              wget -qO- "http://archive.apache.org/dist/maven/maven-3/3.1.1/binaries/apache-maven-3.1.1-bin.tar.gz" | tar -zx --strip-components=1 -C /home/user/maven3
    ENV M2_HOME /home/user/maven3   
    RUN echo "export M2_HOME=$M2_HOME" >> /home/user/.bashrc
    ENV PATH $M2_HOME/bin:$PATH
    RUN echo "export PATH=$PATH" >> /home/user/.bashrc
    


    image

    Подобным же образом настраивается любой другой build tool — скачиваем, распаковываем, устанавливаем переменные окружения и записываем их в .bashrc. Конечно же, можно использовать уже готовые имиджи с DockerHub, где все это добро уже предустановлено.

    Что касается добавления исходного кода и артефактов в окружение, то тут разработчики Codenvy предлагают 2 переменные, которые по-разному используются для “сорцов” и для “build артефактов”.

    Чтобы добавить исходный код скриптовых проектов (PHP, Python, AngularJS) используется стандартная Docker инструкция ADD с Codenvy переменной:

    ADD $app$  /destination/path/in/your/image/
    


    По факту скачивается архив со всеми файлами приложения и распаковывается в указанную директорию.

    Такая же иструкция для Maven или Ant проекта заберет build артефакт, который потом уже исполняется или “деплоится”, например в Tomcat-е:

    ADD $app$  /home/user/tomcat7/webapps/ROOT.war
    


    А если нужно забрать sources Java проекта и собрать его в рантайме, используем:

    ADD $app_src$ /destination/path/in/your/image
    


    В случае использования предустановленного runtime или же наследования имиджей Codenvy, предлагается SSH доступ в запущенный контейнер. Так, например, в качестве CMD команды можно прописать бесконечный цикл:

    CMD white true; do true; done 
    


    и выполнять команды руками во вкладке Terminal.

    image

    В качестве SSH терминала используется Shellinabox, впрочем, пользователь вправе использовать “что-то свое” — iframe во вкладке Terminal слушает 4200 порт. EXPOSE портов работает так же, как и при локальном билде образа. Существует лишь одно условие, если вы открываете порт, “клиенту” нужно знать, где забирать URL терминала и приложения. Для этого используются специальные переменные:

    Для терминала:

    ENV CODENVY_WEB_SHELL_PORT <port>
    


    Для приложения:

    ENV CODENVY_APP_PORT_<port>_HTTP <port>
    


    Например, если ваш Tomcat работает по стандартному порту 8080, то переменная и ее значение будут выглядеть следующим образом:

    ENV CODENVY_APP_PORT_8080_HTTP 8080
    


    Вот, собственно, и все “правила” использования Docker в Codenvy. Все остальное зависит от имеющихся ресурсов и фантзии пользователя. Импортировали проект, создали среду разработки, добавили исходный код, собрали и запустили проект — все в браузере. Из интересностей — использование VNC для запуска десктопных и мобильных приложений (например, Android эмулятор), а также live-reload для скриптовых языков (в предустановленном окружении директория с исходным кодом проекта монтируется в имидж, что позволяет подхватывать изменения без необходимости перезапускать приложение — все как и локально на десктопе).

    'Шаринг' среды разработки

    Наверное, многие из вас сталкивались с ситуацией, когда коллеге необходимо запустить ваш проект у себя на машине. Или не коллеге, а клиенту. Акцептанс или дев-сервер, скажем, не подходят по каким-то причинам. С проектом все ок, приложение работает как часы, да только вот среда под него не из простых. И Docker у клиента на виндовом лептопе не установлен, а вам нужен только Debian c Node, npm, nvm, grunt, gulp, bower и какие-то еще Ruby gems. Да, есть «дока». Но, вроде бы давненько вы ее не обновляли, и вроде как в последний раз нужно было немного танцевать с бубном, а то не «заводился» проект. Конечно, это не сплошь типичная ситуация, но бывает. И после пол-дня мучений, коллега или клиент говорит — «Не работает». Ну, а вы, как настоящий программист, говорите «Ну, не знаю. У меня работает».

    Как такую проблему решают, или пытаются решить, в Codenvy? Фишка называется Factories. В открытом проекте, пользователь генерит URL c хеш-кодом, в котором зашифрованы десятки параметров, касающиеся самого проекта, его среды, поведения IDE… Специально обученный API получает POST запрос с этими параметрами и выдает URL, например https://codenvy.com/f?id=djbxklig6ihr3cgn (открывать в новой вкладке).

    Кликнув по ссылке, видим, что создается временный workspace, куда клонируется исходный код проекта. Нажав на кнопку Run, собираем и запускаем Docker имидж. В инструкциях прописан билд с помощью Grails и деплой war в Tomcat. При каждом нажатии на URL создается новый временный воркспейс. Таким образом, линк один — а идентичных environments хоть сотня. При этом пользователь может править исходный код, вносить изменения и пересобирать/перезапускать приложение. Через некоторое время такой одноразвый воркспейс умирает, а фраза «Не знаю, у меня работает» не нужна в принципе.

    URL генерится прямо в UI, однако существует и advanced способ с использованием CLI или API, и JSON-а с набором параметров, в которых можно указать RAM, необходимый для «взлета» приложения, среду, в которой нужно запускать проект, «прописку» исходного кода (Git URL с GitHub, например), действия после создания временного воркспейса (открытие файла README, например), ограничения доступа, замена текста и переменных.

    Еще один пример. Node.js приложение, работающее с MongoDB https://github.com/andzdroid/mongo-express. Чтобы запустить локально, нужно установить много чего. Или же воспользоваться «фабрикой», запустить приложение во временном воркспейсе, стартонуть Mongo как daemon и запустить само Node приложение (открывать в новой вкладке):



    Плюсы:

    • не нужно устанавливать Docker
    • не нужно качать имидж (единожды «стянув имидж», он остается в кеше Docker-а на инстансе раннера)
    • запуск в 2 клика — сам URL и кнопка Run в Codenvy


    Минусы. Их, конечно, найти несложно. Ну, не угнаться облачным IDE за IntelliJ и Eclipse. Функции редактора ограничены. Кстати, Codenvy можно использовать в связке с вышеупомянутыми IDE. Для Eclipse есть специальный плагин, с помощью которого можно импортировать проекты из Codenvy в Eclipse, редактировать в любимой IDE, а собирать и запускать проекты в облаке. В принципе, можно использовать любую IDE в связке с Codenvy CLI — синхронизация исходного кода, удаленная сборка и запуск проектов — все это предлагается в Codenvy CLI.

    На данный момент, если билд приложения проходит в Docker-е, то «клиент», а конкретно, Java editor ничего про это не знает. Отсюда остуствие code autocompletion и false errors. Помощник в написании кода также отсутствует для всех языков, кроме Java. Проблема, по словам сами разработчиков, будет решаться, так как билдеры также будут переведены в Docker в ближайшем будущем.

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

    И напоследок, неколько Factories (открывать в новых вкладках)

    Android File Manager, собранный Gradle-ом и запущенный в дефолтном Android эмуляторе (см. инструкции в WELCOME файле):



    Java GAE приложение, запущенное средствами Java GAE SDK. Перейдя во вкладку Terminal, можно «задеплоить» приложение на GAE (инструкции в WELCOME файле, не забываем указать ваш application ID в appengine-web.xml). Кстати, полноценная интеграция с GAE на подходе.



    AngularJS проект:



    Вместо выводов

    Что ж, с неистовым прогрессом Docker, стало понятно, что облачные IDE, и Codenvy, в частности, не ставят себе цель — заменить собой desktop. Как не крути, а локальная среда и ближе и понятней. Вместе с тем, возможность создания среды разработки в браузере, и эффективный «шаринг» проектов+runtime может существенно облегчить жизнь при определенных обстоятельствах. Так, например, томные инструкции, начинающиеся с «установите Java, Maven, m2 plugin и еще с десяток тулзовин», можно заменить на одну кнопку или линк, и пользователю не нужно скачивать пол-Интернета, чтобы опробовать в действии фреймворк или новую библиотеку. Из последних примеров — testing framework Arquillian. Обратите внимание на количество инструкций в Getting Started по ссылке. А вот тоже самое, но в фабрике Codenvy (открывать в новой вкладке):



    Вместо эпилога

    Лабу по 'плюсам' нужно было сделать. Устанавливать все было лень. Заюзал Codenvy. Это комментарий одного из пользователей.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 17

      +9
      докер имиджи

      Ужас какой: вы слово image либо не переводите вообще(в смысле английским и пишите), либо переводите, как «образ».
      0
      Хот деплой никак не получилось настроить. Без него такой вариант разработки терят в привелкательности. А может это у меня руки не из того места растут.
        0
        Пока что live reload работает для предустановленных окружений, а когда свой Dockerfile, то такой функционал теряется. В ближайшем будущем пофиксится.
        0
        Идея с шарингом очень правильная. Помню на прошлой работе доросли до того, что любой проект начинался с виртуальной машины, на которой все должно собираться. Чтобы сборка ни в коем случае не зависела от окружения на локальной машине конкретного разработчика.
          0
          Да, и стоит все-таки упомянуть общий минус облачных IDE — зависимость от хорошего канала интернета. Взять с собой работу в глухую деревню уже не получится.
            0
            Верно, интернет нужен, и желательно хороший, иначе user experienceбудет «не ахти». Решение есть, вернее, воркэраунд — синхронизация с десктопом. То есть поработал локально, как только инет появился запушил изменения в клауд.
              0
              То есть поработал локально, как только инет появился запушил изменения в клауд.
              Так придется уже два окружения настраивать и поддерживать в идентичном состоянии.
              А Docker не имеет планов сделать механизм выдачи инстанса «на руки», чтобы запускать локально? Это кстати не только для глухих деревень решение будет, но и для предприятий с повышенным уровнем сетевой безопасности.
                +2
                Так он это из коробки умеет.
                  0
                  Хм. Да, это я не разобрался в технологии. Что ж, это очень круто!
                  0
                  в планах интеграция с докер хабом, логин и пуш результирующего имиджа на хаб — в таком случае окружение будет доступно и для Unix и Windows клиентов Docker через docker pull image/name

                  Dockerfile в Codenvy ничем не отличается от Dockerfile, который вы пишете локально и из него собираете имидж (уж простите за слово: ). Специфика только в условиях добавления сорцов и артефактов, а также работа с портами.
              +3
              >Docker нынче не использует только ленивый.
              Ну почему же. А также тот, кто впервые о нём услышал.
                0
                1. Создал JS Basic Project.
                2. Создал скрипт, введя имя script.js.
                3. Заметил, что файл получил имя script.js.js.
                4. Решил переименовать. Переименовал в script.js.
                5. В редакторе кода осталась закладка со старым именем файла.
                6. Закрыл закладку файла в редакторе кода.
                7. Попытался двойным кликом снова открыть на редактирование файл script.js — не открывается ни в какую.
                8. Перезагрузил страницу и файл script.js открылся на редактирование по двойному клику.
                  0
                  баг.

                  А насчет Докера, не поймите неправильно — уж очень за год Docker шагнул…
                  0
                  Докер, докер, докер. Всё только о нём и говрят.
                  Пошёл ставить и разбираться… Есть предчувствие, что будет «отвал башки» в хорошем понимании (-:

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

                  Самое читаемое