Настройка среды разработки: кофейная гуща (Часть 2)

    Настройка среды разработкиПривет, дорогой читатель!
    В этот раз я хочу поделиться своим результатом настройки персонального окружения для работы с различными PHP-based проектами с использованием Puppet. В данной статье описываются результаты, которые были получены в процессе изучения и написания Puppet конфигурации.

    Данная статья написана с целью показать один из способов это сделать. Я не хочу призывать к действию, а только делюсь тем, с чем я столкнулся, что сделал и как использую.

    Статья будет очень длинной с уклоном в техническую сторону. Прошу под «кат».

    Какое-то время назад мною была написана статься «Настройка среды разработки: кружок рукоделия (Часть 1)», в которой я описал свои мучения при каждой смене проекта. При подготовке этой статьи были добавлены и убраны некоторые компоненты среды. В конце статьи будет ссылка на репозиторий с модулем, который вы можете разорвать на части использовать и модифицировать по своему усмотрению.

    Цель: быстро настроить рабочую среду под текущий проект


    Цель та же, но с небольшим дополнением: если можешь автоматизировать, то сделай это.

    Puppet


    Это хороший инструмент, которые поможет вам в управлении конфигурацией различных операционных систем.

    Выбор пал именно на этот инструмент, так как этот инструмент используется в компании, а мне необходимо знать, что происходит за кулисами у DevOps / NetOps.

    Таким образом в процессе описания конфигурации, я получил следующее:

    — PHP (5.6, 7.x; pools для каждого проекта; расширения; composer)
    — NGINX (PHP-FPM upstream для каждого проекта; Простая конфигурация vhost)
    — OpenSSL
    — MySQL
    — Bind9
    — NodeJS + NPM
    — Memcached
    — Redis
    — Docker
    — Дополнительное ПО: mc, htop, wget, curl

    Конфигурация


    Так как я храню реальную конфигурация в приватном репозитории, то вашему вниманию я предлагаю ознакомится с учебной версией, которую я буду описывать в этой статье.

    Внимание: данные репозиторий поставляется как есть. Дальнейшая судьба проекта — стать более гибкой основой или умереть.

    При разработке костыля конфигурации я использовал возможности Puppet Hiera и r10k (инструмент для удобного разворачивания конфигурации).

    Основой код, который отвечает за установку пакетов, создание файлов и перезапуск сервисов находится в ветке 'production'. Используя возможности Puppet Hiera я предоставил возможность настраивать конфигурацию текущего узла, которая определяется по FQDN рабочей машины. Таким образом один из примеров конфигурации можно найти по пути:

    hieradata/nodes/dev.lo.yaml
    ---
    # Node with all in one
    
    classes:
      - role::all
    
    composer: true
    
    projects:
        warface:
            - {name: 'www', php: php7.0}
            - {name: 'imageproxy', php: php5.6}
    
        cryengine:
            - {name: www, php: php7.1}
            - {name: shop, php: php7.1}
            - {name: forum, php: php5.6}
    
    php:
      versions: [php5.6, php7.0, php7.1, php7.2]
      packages: [
          opcache, gd, bcmath, curl, intl, json, mbstring,
          mysql, readline, soap, sqlite3, tidy, xml, zip,
          codecoverage, codesniffer, igbinary, geoip, imagick,
          memcache, memcached, redis, xdebug, ssh2
      ]
    
    tools: [imagemagick]
    
    bind9:
      dns: ['8.8.8.8', '8.8.4.4']
    


    которая будет объединена с

    hieradata/common.yaml
    ---
    # Puppet Server Tuning
    puppet_enterprise::master::puppetserver::jruby_max_requests_per_instance: 0
    
    classes:
      - role::default
    
    composer: true
    
    nginx:
      domain: "%{::fqdn}"
    
    projects:
        development:
            - name: 'www'
              php: 'php7.0'
    
    php:
      versions: [php7.0]
      packages: [
        curl, mbstring, xml, json, intl, xdebug
      ]
    
    tools: [mc, htop, wget, curl]
    
    db:
      mysql:
        root_password: root
        remove_default_accounts: true
        override_options: {}
    
    bind9:
      dns: ['8.8.8.8', '8.8.4.4']
      zone: "%{::fqdn}"
    


    В результате выполнения данной конфигурации будет установлен весь изначальный список компонентов, а так же на сервере будут следующие особенности:

    1) Создана конфигурация для NGINX + PHP-FPM для следующих проектов:
    www.warface.lo (php7.0)
    — imageproxy.warface.lo (php5.6)
    www.cryengine.lo (php7.1)
    — shop.cryengine.lo (php7.1)
    — forum.cryengine.lo (php5.6)
    2) Установлены следующие версии PHP с соответствующими модулями: 5.6, 7.0, 7.1, 7.2
    3) Будет установлен пакет imagemagick
    4) Обновлен OpenSSL до последней доступной версии
    5) MySQL root/root
    6) Redis и Memcached сервисы
    7) Последние версии Composer, NodeJS и NPM
    8) Сервер bind9 + его конфигурация, которая позволяет «резолвить» запросы домена *.lo на текущий хост.
    9) Docker

    Структура


    Структура репозитория объединяет в себе следующие понятия:
    master branch — контрольный репозиторий (control-repo)
    production branch — описание конфигурации 'production'

    Установка


    Процесс запуска сводится к нескольким простым шагам:

    1) Установка git + puppet + r10k
    2) Инициализация «control-repo»
    2) Разворачивание конфигурации с помощью r10k
    3) Запуск puppet apply

    bash
    #!/bin/bash
    
    echo "Initialize"
    # https://docs.puppet.com/puppet/5.1/install_linux.html
    # https://docs.puppet.com/puppet/5.1/puppet_platform.html
    wget --no-verbose https://apt.puppetlabs.com/puppet5-release-xenial.deb
    dpkg -i --force-confdef puppet5-release-xenial.deb
    rm -f puppet5-release-xenial.deb
    
    echo "[APT]: ===="
    apt-get update
    sudo apt-get upgrade -y
    apt install -o Dpkg::Options::="--force-confold" -y git puppet-agent r10k
    
    echo "[APT]: Puppet"
    export PATH=/opt/puppetlabs/bin:$PATH
    echo "Puppet version is $(puppet --version)"
    
    echo "[PUPPET]: Control Repo"
    git clone https://github.com/OxCom/puppet-php-skeleton-dev.git
    cp -rf ./puppet-php-skeleton-dev/* /etc/puppetlabs/puppet/
    rm -rf ./puppet-php-skeleton-dev
    
    echo "[SSH]: ===="
    echo "[SSH]: Hosts"
    ssh-keygen -R bitbucket.org
    ssh-keyscan bitbucket.org >> ~/.ssh/known_hosts
    ssh-keygen -R github.com
    ssh-keyscan github.com >> ~/.ssh/known_hosts
    
    echo "[PUPPET]: ===="
    echo "[PUPPET]: Running R10K"
    cd /etc/puppetlabs/puppet
    r10k deploy environment -p -v
    
    echo "[PUPPET]: Running puppet"
    puppet apply /etc/puppetlabs/puppet/environments/production/manifests/site.pp --confdir=/etc/puppetlabs/puppet --environment=production --environmentpath=/etc/puppetlabs/puppet/environments/
    


    Дальнейшая модификация


    Ниже приведен список того, как можно улучшить текущую конфигурацию и сделать ее более гибкой:

    — Добавить классы, описывающие процесс разворачивания проекта (git clone, специфические vhost, настройки приложения, разворачивание базы: пользователь + схема + данные)
    — Добавить классы запуска контейнеров для docker
    — Генерация сертификатов (NGINX + HTTPS)

    Реализация далека от идеала и не всегда следует правилам, но вот что хотелось бы выделить:

    — Всегда думайте о зависимостях, так как Puppet не гарантирует инициализацию классов в порядке их подключения;
    — Описывайте с помощью hiera параметры, которые изменяют поведение класса;
    — Не забывайте про параметры по умолчанию;
    — Не изобретайте велосипед: возможно кто-то уже сделал тот функционал, который вам необходим.

    Полезные ссылки


    Документация Puppet
    R10K
    Puppet Модули
    Puppet Cookbook
    Настройка среды разработки: кружок рукоделия (Часть 1)

    P.S.: Если вы найдете какие-либо вещи в репозитории, которые можно улучшить, то напишите мне об этом и с примером или ссылкой, как это можно изменить.
    • +10
    • 5,1k
    • 3
    Поделиться публикацией
    Комментарии 3
      0

      а почему не vagrant? почему не docker?

        0
        Vagrant:
        В репозитории есть пример, как запустить это дело с vagrant. Vagrant сейчас использую только для поднятия стабильных версий проектов, когда ожидается поведение: поднял и забыл или тестирование.

        Docker:
        Засунуть NGINX, PHP-FPM разных версий, Bind9, DB и все остально – это здорово, но когда приходится ковырятся в исходниках того же NGINX или PHP, изучая почему что-то упало причины странного поведения, то лучше иметь все локально.
        Так же есть очень неприятный факт, что не все разработчики идут в ногу с текущими реалиями разработки: некоторые все еще игнорируют CI/DC, Composer, NodeJS, виртуальные машины, а docker для них как телевизор, который излучает радиацию. И с ними нужно считаться, но это другая история о том, как устраиваются родсвенники начальников и т.п.

        У меня есть в планах написать статью, как это сделать с помощью docker, но прежде всего мне нужно донести и обкатать это на коллегах.
          0
          Засунуть NGINX, PHP-FPM разных версий, Bind9, DB и все остально – это здорово

          не надо ничего никуда засовывать, у вас уже есть готовые образы. Да и непонятно для чего bind9, есть всякие nginx-proxy и тд.


          некоторые все еще игнорируют CI/DC

          я могу вам сказать что даже среди тех кто не игнорирует CI/CD количество людей которые реально это используют составляют меньшинство.


          а docker для них как телевизор, который излучает радиацию. И с ними нужно считаться

          С чего бы это? Может быть не надо потворствовать безграмотности?

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

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