Разработка на Django под Windows с помощью Docker-machine



    В этой статье я расскажу как я решил проблему настройки окружения для разработки на Django под Windows.
    Используется следующая связка:
    1) Docker-machine
    2) PyCharm
    В Docker-machine:
    1) PostgreSQL
    2) Data container для PostgreSQL
    3) Redis
    4) И собственно само приложение на Django.



    Сперва нам нужно установить Docker-machine в систему. Для этого скачиваем с официального сайта docs.docker.com/engine/installation/windows. Так же нам понадобится VirtulaBox.
    После установки в системе появится Docker Quickstart Terminal. Нужно его запустить и он запустит docker-machine, с которой в дальнейшем и будет проходить всё взаимодействие.
    После того как docker-machine будет запущена, через этот терминал мы сможем выполнять docker команды.


    Для того, чтобы запустить PostgreSQL и Redis, и для дальнейшего автоматического старта этих контейнеров при запуске docker-machine, создадим файл docker-compose.yml:
    postgres:
      restart: always
      image: postgres:latest
      volumes_from:
        - data
      ports:
        - "5432:5432"
    
    data:
      restart: always
      image: postgres:latest
      volumes:
        - /var/lib/postgresql
      command: "true"
    
    redis:
      restart: always
      image: redis:latest
      ports:
        - "6379:6379"
    


    Через терминал нужно перейти в директорию с этим файлом и выполнить команду docker-compose up -d.
    После того, как контейнеры запустятся их можно проверить командой docker ps. Эта команда должна показать примерно следующий результат:


    Сейчас с компьютера можно например с помощью pgadmin подключиться к PostgreSQL по адресу: 192.168.99.100:5432.

    Само приложение Django мы будем запускать при помощи PyCharm. Но для начала в корне созданного проекта создаем файл: Dockerfile с содержимым:
    FROM django:onbuild
    

    Так же в корне проекта должен лежать файл requirements.txt, если конечно используются какие-либо внешние зависимости.
    Пример файла requirements.txt:
    Django==1.9.4
    psycopg2==2.6.1
    gunicorn==19.4.5
    redis==2.10.5
    django-celery==3.1.17
    

    В терминале выполняем команду docker build -t container_name path_to_docker_file .
    Первый запуск займёт достаточно продолжительное время, так как будет скачан базовый образ и установлены все зависимости из файла requirements.txt.

    После того, как образ с приложением будет создан, нужно проект в PyCharm и настроить удалённый интерпретатор. Для настройки нужно зайти в settings -> Project: project_name -> Project interpreter. В строке выбора интерпретатора выбрать пункт add remote.

    Далее нужно подтвердить все изменения, если потребуется перезапустить PyCharm, если IDE не будет видеть пакетов.
    И можно запускать проект. По умолчанию он будет запущен по адресу: 192.168.99.100:8000

    При необходимости можно запускать удаленный manage.py из PyCharm, либо заходить, через docker в контейнер и выполнять нужные команды оттуда.
    Поделиться публикацией

    Похожие публикации

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

      0
      А эксплуатируете как?
        0
        Не совсем понял вопроса. После того как запускаю PostgreSQL и Redis через docker-compose они стартуют вместе с docker-machine. А разработка вся ведется в PyCharm с использованием удалённого интерпретатора, то есть работаю так же как и с локальным. Контейнер сам подхватывает изменения и рестартует при необходимости. Для production я так же использую докер, но уже нативный на linux, и всё запускаю через docker-compose.
          0
          Я про реальный опыт. Насколько долго оно работает, насколько устойчиво, какие проблемы возникают?
          База тоже в докере?
            0
            Да, база так же в докере, используется data контейнер, так что данные не пропадают после того, как контейнер перезапускается.
            Проблемы в принципе могут быть разные, в зависимости от конфигурации да и то, от того что невнимательно читал документацию чаще всего. Пока для меня данная конфигурация даёт больше удобств, чем каких-то проблем.
              0
              Само собой, не в UnionFS же с докером класть данные.
              Но кто юзал докер под нагрузкой, говорили, что ему часто «отрывает» примонтированный раздел — просто база внутри контейнера переставала его видеть и в итоге базе сильно плохело. Поэтому сейчас важны реальные отзывы пользователей. Отсюда и вопрос под насколько большой нагрузкой и как долго эксплуатировали?
                0
                тут вы вряд ли ответ получите, так как статья про разработку под докером, а не продакшн.

                я тоже юзаю докер для Rails в дев-режиме, тоже база в контейнере и редисы в своих контейнерах и сфинкс в своем (и все это в двойном экземпляре для тестового окружения) и все замечательно

                но опять же это все development — тут нет высокой нагрузки
                  0
                  Ну да, всё правильно. Я поэтому вопроса и не понял. Всё-таки статья про dev
                  0
                  Не подскажите, а сейчас как актуальнее всего разворачивать Django в продакшен? У меня просто был перерыв в года 1.5 в разработке на нём, раньше пользовался Gunicorn. Сейчас все больше вижу статей про docker, vergant и прочее. Как сейчас обычно делают? Поверить в контейнеры и пользоваться уже спокойно ими или лучше делать все как раньше через инструменты на подобии gunicorn ( в свое время прост опришёл с RoR, поэтому сразу стал использовать аналог, но как правильно сейчас в экосистеме Django не особо могу понять ).
                    0
                    Да как удобнее в принципе. Docker сейчас это стильно, модно, молодежно) Он даёт некоторые преимущества, например можно легко поднять тестовое окружение идентичное продакшену. Но я к сожалению не так долго использую докер, и тем более под большими нагрузками, чтобы давать советы по поводу нужно ли вам его использовать на продакшене. Может кто использует такую связку в продакшене, нам напишет.
                      0
                      Да понятно, что это тренд, просто думаю дошло все это до этапа, когда можно развернуть заказчику контейнер и сказать так правильно, или на собеседовании ответить, что уже все через Docker гоняю, а gunicorn'ы прошлый век…
                        0
                        Так а в докере то все равно gunicorn, просто используете вы в основном уже настроенный образ.
                        0
                        > Docker сейчас это стильно, модно, молодежно)
                        А для эксплуатации ждать Docker 2.0 и потом на него переходить.
                        > тестовое окружение идентичное продакшену.
                        Не очень понял за счет чего, если оно создается разными инструментами. Значит между ними всегда будет расхождение.
                          0
                          Почему разными? Тестовое можно при желании поднять так же как и продакшен только на других железках
                            0
                            Потому что бой у вас поднимается с помощью рук/puppet/chef/ansible/salt/…, а тест докером. Обязательно какие-то расхождения да будут.
                        0
                        Сравнивать Docker и gunicorn — это как тёплое с мягким. Они не заменяют друг друга. Использование Docker или Vagrant не избавляет вас от необходимости запустить Django-проект в каком либо production ready веб-сервере (gunicorn, uwsgi и др.)
                          0
                          верно, просто можно запускать gunicorn`ом либо сразу в системе, либо в докер контейнере.
                          Пример из docker-compose:
                          command: /usr/local/bin/gunicorn project.wsgi:application -w 2 -b :8000 --reload

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

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