Тестовый сервер для команды разработчиков
Содержание
Тестовый сервер для команды разработчиков
Вводная
- Один тестовый сервер
- Gitlab и redmine на другом сервере
- Желание разобраться в проблеме
Все сервера находятся в нашей локальной сети, тестовый сервер недоступен извне.
- Возможность тестировать несколько проектов/веток одновременно
- Разработчик может зайти на сервер, до настроить его и при этом не сломать ничего у других
- Все должно быть максимально удобно и делаться по 1 кнопке желательно из gitlab (CI/CD).
Варианты решений
1. Один сервер, много хостов
Самый простой вариант. Используем тот же тестовый сервер, только разработчику нужно создавать хост под каждую ветку/проект и вносить его в конфигурацию nginx/apache2.
- Быстро и всем понятно
- Можно автоматизировать
Минусы:
- Не выполняется п.2 из требований — разработчик может запустить обновление бд и при некотором стечении обстоятельств положить все (Привет Андрей!)
- Довольно сложная автоматизация с кучей конфигурационных файлов
2. Каждому разработчику по серверу!
Выделяем каждому по серверу и разработчик сам отвечает за свое хозяйство.
- Разработчик может полностью настроить сервер под свой проект
Минусы:
- п.2 требований так и не выполняется
- Дорого и ресурсы могут просто простаивать пока идет разработка, а не тестирование
- Автоматизация еще сложней чем в п.1 из-за разных серверов
3. Контейнеризация — docker, kubernetes
Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы. Позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть перенесён на любую Linux-систему с поддержкой cgroups в ядре, а также предоставляет среду по управлению контейнерами.
- Используется один сервер
- Выполняются все пункты требований
Минусы:
- Образы и контейнеры порой отнимают довольно много места, приходится кроном чистить уже устаревшие для освобождения места.
Внедрение docker
При использовании gitlab очень часто попадались на глаза настройки AutoDevOps, kubernetes. Плюс бородатые дядьки на различных meetup рассказывают как у них круто все работает с kubernetes. Поэтому было принято решение попробовать развернуть кластер на своих мощностях, был выпрошен сервер (а тестовый трогать нельзя, там люди тестируют) и понеслась!
Так как опыта у меня с kubernetes 0, делось все по мануалу с попыткой понять как все эти кластера работают. Спустя некоторое время мне удалось поднять кластер, но потом пошли проблемы с сертификатами, ключами, да и вообще с трудностью развертывания. Мне же нужно было решение проще, чтобы научить своих коллег с этим работать (например, тот же отпуск не хочется проводить сидящим в скайпе и помогающим с настройкой). Поэтому kubernetes был оставлен в покое. Оставался сам docker и нужно было найти решение для маршрутизации контейнеров. Так как их можно было поднять на разных портах, то можно было бы использовать тот же nginx для внутреннего перенаправления. Называется это обратный прокси сервер.
Обратный прокси-сервер — тип прокси-сервера, который ретранслирует запросы клиентов из внешней сети на один или несколько серверов, логически расположенных во внутренней сети. При этом для клиента это выглядит так, будто запрашиваемые ресурсы находятся непосредственно на прокси-сервере.
Обратный прокси-сервер
Чтобы не изобретать велосипед, я начал искать готовые решения. И оно нашлось — это traefik.
Træfik — это современный обратный прокси HTTP и балансировщик нагрузки, который упрощает развертывание микросервисов. Træfik интегрируется с существующими инфраструктурными компонентами ( Docker, Swarm mode, Kubernetes, Marathon, Consul, Etcd, Rancher, Amazon ECS, . ) и настраивается автоматически и динамически. Для работы с docker достаточно указать его сокет и все, дальше Træfik сам находит все контейнеры и маршрутизацию до них (подробнее в «Упаковываем приложения в docker»).
Запускаю его через docker-compose.yml
Здесь мы сообщаем прокси, что нужно слушать порты 80,443 и 8080 (веб морда прокси), монтируем сокет докера, файл конфигурации и папку с сертификатами. Для удобства именования тестовых сайтов, мы решили сделать локальную доменную зону *.test. При обращении к любому сайту на ней, пользователь попадает на наш тестовый сервер. Поэтому сертификаты в папке traefik самоподписаные, но он так поддерживает Let’s Encrypt.
Перед стартом нужно создать в докере сеть proxy (можете назвать по своему).
Это будет сеть для связи traefik с контейнерами php сайтов. Поэтому указываем ее в параметре networks сервиса и в networks всего файла указав в параметре external: true.
Тут все довольно просто — указываем точки входа http и https трафика, не забудьте поставить insecureSkipVerify = true если сертификаты локальные. В секции entryPoints.https.tls можно не указывать сертификаты, тогда traefik подставит свой сертификат.
Можно запустить сервис
Если перейти по адресу site.test, то выдаст ошибку 404, так как этот домен не привязан ни к какому контейнеру.
Упаковываем приложения в docker
Теперь нужно настроить контейнер с приложением, а именно:
1. указать в сетях сеть proxy
2. добавить labels с конфигурацией traefik
Ниже приведена конфигурация одного из приложений
В сервисе app, в секции сети нужно указать proxy и default, это значит что он будет доступен в двух сетях, как видно из конфигурации я не пробрасываю порты наружу, все идет внутри сети.
Далее конфигурируем labels
В общей секции networks нужно указать external: true
Константу TEST_DOMAIN нужно заменить на домен, например, site.test
Теперь если зайти на домены site.test, crm.site.test, bonus.site.test можно увидеть рабочий сайт. А на домене pma.site.test будет phpmyadmin для удобной работы с бд.
Настройка GitLab
Создаем обработчик заданий, для этого запускаем
Указываем url gitlab, токен и через что будет выполняться задание (executors). Так как у меня тестовый и gitlab находятся на разных серверах, то выбираю ssh executor. Нужно будет указать адрес сервера и логин/пароль для подключения по ssh.
Runner можно сделать прикрепленным к одному или нескольким проектам. Так как у меня логика работы везде одинаковая, поэтому был создан shared runner (общий для всех проектов).
И последний штрих это создать файл конфигурации CI
В данной конфигурации описаны 2 этапа — build и clear. Этап build имеет 2 варианта выполнения — build_develop и build_prod
Gitlab строит понятную диаграмму выполнения процесса. В моем примере все процессы стартуют вручную (параметр when: manual). Сделано это для того, чтобы разработчик после разворачивания тестового сайта, мог делать pull своих правок в контейнер без пересборки всего контейнера. Еще одна причина это наименование доменов — site$CI_PIPELINE_ID.test, где CI_PIPELINE_ID — номер процесса запустившего сборку. То есть отдали на проверку сайт с доменом site123.test и чтобы внести горячие правки, сразу заливаются изменения в контейнер самим разработчиком.
Небольшая особенность работы ssh executor. При подключении к серверу создается папка вида
Поэтому была добавлена строчка
В ней мы поднимаемся на папку выше и копируем проект в папку с номером процесса. Так можно разворачивать несколько веток одного проекта. Но в настройках обработчика нужно поставить галку Lock to current projects, так обработчик не будет пытаться развернуть несколько веток одновременно.
Этап clear останавливает контейнеры и удаляет папку, могут понадобиться права root, поэтому используем команду echo password | sudo -S rm, где password ваш пароль.
Уборка мусора
Время от времени нужно удалять не используемые контейнеры, чтобы не занимать место, для этого в кроне висит скрипт с таким содержанием
выполняется раз в день.
Заключение
Данное решение помогло нам существенно оптимизировать тестирование и выпуск новых фич. Готов ответить на вопросы, конструктивная критика принимается.
Бонус
Для того чтобы не собирать каждый раз образы из Dockerfile, можно хранить их локальном реестре докера.
В данном варианте не используется аутентификация, это не безопасный способ (. ), но для хранения не критичных образов нам подходит.
Можно настроить gitlab для просмотра
После этого в gitlab появляется список образов
Загрузка необходимых файлов на веб-сервер
Лучшие цены на SSL-сертификаты (от 550 руб.)
- Все доверенные центры сертификации
- Большой выбор сертификатов
- Пошаговые инструкции по выпуску и установке
Прежде всего, необходимо загрузить представленные в панели 1cloud файлы .ca и .crt на веб-сервер. Если ваш сервер не имеет графического окружения рабочего стола, вы можете загрузить эти файлы на другой компьютер, а затем перенести их одним из приведенных ниже способов.
Примечание: подразумевается, что необходимая для работы пара закрытый/открытый ключ была сгенерирована на том же веб-сервере, на который вы будете переносить приобретенный сертификат. Если вы создавали ключи на другой машине, вам необходимо также перенести файл закрытого ключа .key на ваш веб-сервер по аналогии с описанной ниже процедурой копирования файлов сертификатов.
Перенос сертификатов с компьютера Linux/Mac OS:
Самый простой способ загрузки сертификатов на сервер — опция SCP, встроенная в возможность терминала вашего компьютера:
- Загрузите файлы .CA и .CRT из панели управления 1cloud на локальный компьютер.
- Откройте терминал и перейдите в папку, в которую вы сохранили сертификаты (напр., Downloads):
cd
/Downloads
Скопируйте сертификаты вашего сайта и Центра Сертификации на веб-сервер:
scp crt.crt ca.crt user@1.22.33.444:/etc/ssl
Где:
scp — команда копирования файлов
mydomain.ru_crt.crt — имя загруженного из панели файла сертификата вашего веб-сайта
mydomain.ru_ca.crt — имя загруженного из панели файла сертификата Центра Авторизации
user — имя вашего пользователя для подключения к серверу через ssh (часто используется root)
1.22.33.444 — IP-адрес вашего веб-сервера
/etc/ssl — директория на удаленном сервере, в которую в хотите сохранить загружаемые файлы.
Перенос сертификатов с компьютера Windows:
- Установите программу WinSCP. Скачать ее можно здесь.
- Запустите WinSCP. В открывшемся окне введите данные, которые вы используете для подключени я к вашему серверу по SSH.
В левой части окна программы отображаются файлы на локальном компьютере, в правой — на подключенном удаленном сервере. Выберите или создайте директорию, в которую вы хотите сохранить сертификаты, в правой части окна. Перетащите файлы .CA и .CRT в эту директорию из левой части окна.
Примечение: для удобства в дальнейшем рекомендуем перенести файл закрытого ключа (.key) в ту же директорию, в которую вы скопировали файлы сертификатов. Вы можете не делать этого, но таком случае запомните путь до этого файла и в дальнейшем укажите его в файле конфигурации Apache вместо пути, приведеленного в нашем примере.
Если закрытый ключ .key был сгенерирован непосредственно на сервере, то для его копирования в другую директорию вы можете использовать команду:
cp /home/root/private.key / etc /ssl/private.key
Где:
cp — команда копирования
/home/root/ — путь до файла ключа
private.key — имя файла ключа
/etc/ssl/private.key — путь, по которому необходимо скопировать файл ключа
Удалить файл ключа из старого расположения вы можете с помощью команды:
rm /home/root/private.key
(синтаксис команды аналогичен предыдущему примеру)
Установка NetCat на Windows
В этом руководстве будет рассмотрен процесс установки и использования утилиты netcat на виртуальных серверах под управлением операционной системы семейства Windows.
Виртуальный сервер на базе Windows
- Лицензия включена в стоимость
- Тестирование 3-5 дней
- Безлимитный трафик
Что это такое
Netcat — сетевая утилита, которую часто называют “Швейцарским армейским ножом”, используется для чтения или записи по TCP и UDP соединениям, используя простой интерфейс.
Установка
Загрузите архив с утилитой.
Перейдите в каталог с загрузками и распакуйте содержимое архива в любое удобное место.
В нашем примере мы будем использовать каталог “C:Program filesnetcat”.
При перемещении Вам необходимо ввести пароль “nc”.
Содержимое каталога после перемещения файлов.
Далее откройте командную строку Windows или PowerShell. С помощью команды cd перейдите в каталог с файлами: cd ‘C:Program filesnetcat’
Запустите утилиту netcat: .nc.exe
В поле открывшейся командной строки можно начинать работу с утилитой. Для вывода доступных опций воспользуйтесь ключом -h: nc -h
-d | detach from console, background mode | фоновый режим работы |
-e prog | inbound program to exec [dangerous!!] | программа на исполнение для обмена данными с сетью |
-g gateway | source-routing hop point[s], up to 8 | свободная маршрутизация пакета от источника по указанному маршруту, максимум 8 точек |
-G num | source-routing pointer: 4, 8, 12, … | свободная маршрутизация пакета от источника по указанному количеству указателей |
-h | this cruft | вывод справочной информации |
-i secs | delay interval for lines sent, ports scanned | задержка между отправляемыми данными в секундах |
-l | listen mode, for inbound connects | режим прослушивания порта, для входящих подключений |
-L | listen harder, re-listen on socket close | повторное прослушивание сокета закрытия |
-n | numeric-only IP addresses, no DNS | использование IP-адреса, а не DNS записи |
-o file | hex dump of traffic | вывести дамп данных |
-p port | local port number | локальный номер порта |
-r | randomize local and remote ports | cлучайные локальные и удаленные порты |
-s addr | local source address | определяет заданный IP-адрес для использования |
-t | answer TELNET negotiation | совместимость с telnet |
-u | UDP mode | режим подключения по UDP |
-v | verbose [use twice to be more verbose] | дополнительная диагностика |
-w secs | timeout for connects and final net reads | таймаут подключения в секундах |
-z | zero-I/O mode [used for scanning] | не посылать данные |
Примеры использования
На первой машине с IP-адресом X.X.X.X выполните команду nc с указанием порта, например 80.
Для Linux: nc -l -p 80
Для Windows после запуска утилиты netcat: -l -p 80
На другой машине, которая подключается, выполните команду, указав IP-адрес первой машины и порт.
Для Linux: nc X.X.X.X 80
- Получаем код страницы и дополнительную информацию с помощью GET-запроса. PS C:Program Filesnetcat> .nc.exe
- Сканирование портов. PS C:Program Filesnetcat> .nc.exe PS C:Program Filesnetcat> .nc.exe
- Чат-сервер
Для Windows: X.X.X.X 80
В пустой строке начинайте писать сообщение, после нажатия Enter оно будет отправлено.
Тестовый сервер для команды разработчиков
Вводная
- Один тестовый сервер
- Gitlab и redmine на другом сервере
- Желание разобраться в проблеме
Все сервера находятся в нашей локальной сети, тестовый сервер недоступен извне.
- Возможность тестировать несколько проектов/веток одновременно
- Разработчик может зайти на сервер, до настроить его и при этом не сломать ничего у других
- Все должно быть максимально удобно и делаться по 1 кнопке желательно из gitlab (CI/CD).
Варианты решений
1. Один сервер, много хостов
Самый простой вариант. Используем тот же тестовый сервер, только разработчику нужно создавать хост под каждую ветку/проект и вносить его в конфигурацию nginx/apache2.
- Быстро и всем понятно
- Можно автоматизировать
Минусы:
- Не выполняется п.2 из требований — разработчик может запустить обновление бд и при некотором стечении обстоятельств положить все (Привет Андрей!)
- Довольно сложная автоматизация с кучей конфигурационных файлов
2. Каждому разработчику по серверу!
Выделяем каждому по серверу и разработчик сам отвечает за свое хозяйство.
- Разработчик может полностью настроить сервер под свой проект
Минусы:
- п.2 требований так и не выполняется
- Дорого и ресурсы могут просто простаивать пока идет разработка, а не тестирование
- Автоматизация еще сложней чем в п.1 из-за разных серверов
3. Контейнеризация — docker, kubernetes
Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы. Позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть перенесён на любую Linux-систему с поддержкой cgroups в ядре, а также предоставляет среду по управлению контейнерами.
- Используется один сервер
- Выполняются все пункты требований
Минусы:
- Образы и контейнеры порой отнимают довольно много места, приходится кроном чистить уже устаревшие для освобождения места.
Внедрение docker
При использовании gitlab очень часто попадались на глаза настройки AutoDevOps, kubernetes. Плюс бородатые дядьки на различных meetup рассказывают как у них круто все работает с kubernetes. Поэтому было принято решение попробовать развернуть кластер на своих мощностях, был выпрошен сервер (а тестовый трогать нельзя, там люди тестируют) и понеслась!
Так как опыта у меня с kubernetes 0, делось все по мануалу с попыткой понять как все эти кластера работают. Спустя некоторое время мне удалось поднять кластер, но потом пошли проблемы с сертификатами, ключами, да и вообще с трудностью развертывания. Мне же нужно было решение проще, чтобы научить своих коллег с этим работать (например, тот же отпуск не хочется проводить сидящим в скайпе и помогающим с настройкой). Поэтому kubernetes был оставлен в покое. Оставался сам docker и нужно было найти решение для маршрутизации контейнеров. Так как их можно было поднять на разных портах, то можно было бы использовать тот же nginx для внутреннего перенаправления. Называется это обратный прокси сервер.
Обратный прокси-сервер — тип прокси-сервера, который ретранслирует запросы клиентов из внешней сети на один или несколько серверов, логически расположенных во внутренней сети. При этом для клиента это выглядит так, будто запрашиваемые ресурсы находятся непосредственно на прокси-сервере.
Обратный прокси-сервер
Чтобы не изобретать велосипед, я начал искать готовые решения. И оно нашлось — это traefik.
Træfik — это современный обратный прокси HTTP и балансировщик нагрузки, который упрощает развертывание микросервисов. Træfik интегрируется с существующими инфраструктурными компонентами ( Docker, Swarm mode, Kubernetes, Marathon, Consul, Etcd, Rancher, Amazon ECS, . ) и настраивается автоматически и динамически. Для работы с docker достаточно указать его сокет и все, дальше Træfik сам находит все контейнеры и маршрутизацию до них (подробнее в «Упаковываем приложения в docker»).
Запускаю его через docker-compose.yml
Здесь мы сообщаем прокси, что нужно слушать порты 80,443 и 8080 (веб морда прокси), монтируем сокет докера, файл конфигурации и папку с сертификатами. Для удобства именования тестовых сайтов, мы решили сделать локальную доменную зону *.test. При обращении к любому сайту на ней, пользователь попадает на наш тестовый сервер. Поэтому сертификаты в папке traefik самоподписаные, но он так поддерживает Let’s Encrypt.
Перед стартом нужно создать в докере сеть proxy (можете назвать по своему).
Это будет сеть для связи traefik с контейнерами php сайтов. Поэтому указываем ее в параметре networks сервиса и в networks всего файла указав в параметре external: true.
Тут все довольно просто — указываем точки входа http и https трафика, не забудьте поставить insecureSkipVerify = true если сертификаты локальные. В секции entryPoints.https.tls можно не указывать сертификаты, тогда traefik подставит свой сертификат.
Можно запустить сервис
Если перейти по адресу site.test, то выдаст ошибку 404, так как этот домен не привязан ни к какому контейнеру.
Упаковываем приложения в docker
Теперь нужно настроить контейнер с приложением, а именно:
1. указать в сетях сеть proxy
2. добавить labels с конфигурацией traefik
Ниже приведена конфигурация одного из приложений
В сервисе app, в секции сети нужно указать proxy и default, это значит что он будет доступен в двух сетях, как видно из конфигурации я не пробрасываю порты наружу, все идет внутри сети.
Далее конфигурируем labels
В общей секции networks нужно указать external: true
Константу TEST_DOMAIN нужно заменить на домен, например, site.test
Теперь если зайти на домены site.test, crm.site.test, bonus.site.test можно увидеть рабочий сайт. А на домене pma.site.test будет phpmyadmin для удобной работы с бд.
Настройка GitLab
Создаем обработчик заданий, для этого запускаем
Указываем url gitlab, токен и через что будет выполняться задание (executors). Так как у меня тестовый и gitlab находятся на разных серверах, то выбираю ssh executor. Нужно будет указать адрес сервера и логин/пароль для подключения по ssh.
Runner можно сделать прикрепленным к одному или нескольким проектам. Так как у меня логика работы везде одинаковая, поэтому был создан shared runner (общий для всех проектов).
И последний штрих это создать файл конфигурации CI
В данной конфигурации описаны 2 этапа — build и clear. Этап build имеет 2 варианта выполнения — build_develop и build_prod
Gitlab строит понятную диаграмму выполнения процесса. В моем примере все процессы стартуют вручную (параметр when: manual). Сделано это для того, чтобы разработчик после разворачивания тестового сайта, мог делать pull своих правок в контейнер без пересборки всего контейнера. Еще одна причина это наименование доменов — site$CI_PIPELINE_ID.test, где CI_PIPELINE_ID — номер процесса запустившего сборку. То есть отдали на проверку сайт с доменом site123.test и чтобы внести горячие правки, сразу заливаются изменения в контейнер самим разработчиком.
Небольшая особенность работы ssh executor. При подключении к серверу создается папка вида
Поэтому была добавлена строчка
В ней мы поднимаемся на папку выше и копируем проект в папку с номером процесса. Так можно разворачивать несколько веток одного проекта. Но в настройках обработчика нужно поставить галку Lock to current projects, так обработчик не будет пытаться развернуть несколько веток одновременно.
Этап clear останавливает контейнеры и удаляет папку, могут понадобиться права root, поэтому используем команду echo password | sudo -S rm, где password ваш пароль.
Уборка мусора
Время от времени нужно удалять не используемые контейнеры, чтобы не занимать место, для этого в кроне висит скрипт с таким содержанием
выполняется раз в день.
Заключение
Данное решение помогло нам существенно оптимизировать тестирование и выпуск новых фич. Готов ответить на вопросы, конструктивная критика принимается.
Бонус
Для того чтобы не собирать каждый раз образы из Dockerfile, можно хранить их локальном реестре докера.
В данном варианте не используется аутентификация, это не безопасный способ (. ), но для хранения не критичных образов нам подходит.
Можно настроить gitlab для просмотра
После этого в gitlab появляется список образов
Настройка веб-сервера Apache на использование SSL-сертификата
После копирования файлов сертификата сайта и Центра Сертификации необходимо отредактировать параметры вашего веб-сервера Apache. Для этого подключитесь к вашему серверу по SSH от имени пользователя root и выполните следующие операции:
- Активируйте использование опции SSL веб-сервером Apache:
Ubuntu/Debian:
a2enmod ssl
CentOS:
yum install mod_ssl - Откройте файл конфигурации сайта, для которого вы хотите установить SSL-сертификат.
Например, если параметры веб-сайта хранятся в файле /etc/apache2/sites-enabled/000-default.conf:
nano /etc/apache2/sites-enabled/000-default.conf
Примечание: На Ubuntu/Debian файлы параметров сайтов Apache как правило находятся в директории /etc/apache2/sites-enabled/ . На CentOS стандартное расположение — /etc/httpd/conf.d/
Для поиска нужной конфигурации вы можете использовать команду ls /директория/конфигураций (напр. ls /etc/apache2/sites-enabled), которая отображает полный список файлов в указанной директории.
Затем с помощью команды nano вы можете открыть определенный файл (напр. nano /etc/apache2/sites-enabled/000-default.conf). Проверить, что открытый файл действительно является конфигурацией вашего сайта можно, найдя в нем строку ServerName. Ее значение должно соответствовать домену, для которого вы устанавливаете SSL-сертификат (напр. www.mydomain.ru)
Примечание для CentOS: если редактор nano не установлен на вашем сервере, вы можете установить его с помощью команды yum install nano - Добавьте приведенные ниже параметры в открытый файл конфигурации:
SSLEngine on
SSLCertificateFile /etc/ssl/mydomain.ru_crt.crt
SSLCertificateChainFile /etc/ssl/mydomain.ru_ca.crt
SSLCertificateKeyFile /etc/ssl/mydomain.ru_key.key
Где:
/etc/ssl/mydomain.ru_crt.crt — путь до файла сертификата вашего сайта
/etc/ssl/mydomain.ru_ca.crt — путь до файла цепочки сертификатов Центра Сертификации (CA)
/etc/ssl/mydomain.ru_key.key — путь к файлу вашего закрытого ключа
Примечание: если вы хотите, чтобы после установки SSL-сертификата ваш сайт был доступен только по безопасному протоколу https (порт 443), отредактируйте файл его конфигурации по аналогии с приведенным ниже Примером 1. Если же вы хотите, чтобы сайт также оставался по-прежнему доступен по незащищенному протоколу http (порт 80), воспользуйтесь Примером 2.
Вносимые изменения выделены жирным шрифтом.
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request’s Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.mydomain.ru
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
# Available loglevels: trace8, . trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn
ErrorLog $
CustomLog $
# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with «a2disconf».
#Include conf-available/serve-cgi-bin.conf
SSLEngine on
SSLCertificateFile /etc/ssl/mydomain.ru_crt.crt
SSLCertificateChainFile /etc/ssl/mydomain.ru_ca.crt
SSLCertificateKeyFile /etc/ssl/mydomain.ru_key.key
Пример 2 (HTTPS + HTTP):