UMGUM.COM (лучше) 

Стартовая  →   ( Развёртывание и поддержание сетевой инфраструктуры, конфигурирование коммуникационного оборудования и приложений, инсталляция и сервисное сопровождение серверов, а также консультирование по существу в области сетевого и серверного администрирования. )


Меня зовут Нарожный Андрей и мой стаж деятельности в области информационных технологий превышает полтора десятка лет. Большую часть этого времени я работал на предприятиях вроде системных интеграторов. Если Вы находитесь в поиске того, кто исправит сломанное или сделает так, чтобы всё изначально работало хорошо и долго, то вполне возможно цель достигнута здесь.

Предлагаю услуги удалённого администрирования сетей передачи данных и серверов.

Я разрабатываю планы, внедряю и поддерживаю востребованное в области телекоммуникаций (каналы передачи данных, доступ в интернет, структурированные локальные сети), компьютеризации (оборудование офисов, центров хранения и обработки данных), а также информационных технологий вообще (операционные системы и приложения, программно-аппаратные комплексы), предпочитая решения на базе Cisco и Linux. Документирую процессы и оставляю внятные руководства к действиям. Пишите о своих желаниях.

Чиню то, с чем уже смирились и сочли особенностью реализации.

В динамичном производстве нередко оказываешься перед вышедшим из строя программным или аппаратным обеспечением, которое недокументированно и никем уже не поддерживается. Если в попытках решения вашей беды затупили копья несколько специалистов, вынесших в итоге вердикт "миссия невыполнима", то это повод обратиться ко мне. Я буду разбираться в сути дела до упора и починю неисправность, не затронув при этом существующей схемы взаимодействий, или предложу реалистичный план работ по устранению причин проблемы, если они глобальны.

Делаю так, чтобы всё работало по возможности хорошо и незаметно.

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

Примеры успешно реализованных проектов.

Оформить заявку на проведение работ!

   [ просмотреть в полном объеме ]




Let‘s Encrypt  →   ( Настройка подсистемы получения wildcard-сертификата от "Let's Encrypt", в спарке с NS-серверами "Bind9". )

10 июля 2019

OS: "Linux Debian 7/8/9/10", "Linux Ubuntu 14/16/18 LTS", "Linux Fedora 25/26/27/28/29".
Application: "Certbot v.0.26-35" for "Let`s Encrypt" (on Python), "Bind9".

Задача: наладить запрашивание SSL-сертификата от "Let`s Encrypt", действие которого распространяется на все поддомены одним уровнем выше указанного (включая опорный) - так называемый wildcard-сертификат.

Ранее я уже рассказывал о том, как наладить полуавтоматизированное запрашивание и продление SSL-сертификатов привязанных к одному доменному имени с использованием для подтверждения владением доменом встроенного плагина "webroot", размещающего в указанном месте файловой системы специальный проверочный код, отдаваемый в текстовом файле посредством протокола HTTP. Для wildcard-сертификатов поддерживается только аутентификация посредством создания специальных DNS-записей (метод "dns-01"), основанная на подтверждении владения (управления) DNS-сервером, который поддерживает указанный домен.

   [ уже посетило: 22 ]   [ просмотреть в полном объеме ]


Web  →   ( Развёртывание в среде исполнения "Docker" комплекта web-приложений "Atlassian", таких как "Jira", "Jira Service Desk", "Confluence" и "Crowd". )

24 июня 2019

OS: "Linux Debian 9", "Linux Ubuntu Server 18 LTS".
Apps: "Nginx", "PostgreSQL", "Java", "Docker", "Docker Compose".

Задача: развернуть в среде исполнения "Docker" комплект web-приложений производства "Atlassian", таких как "Jira", "Jira Service Desk", "Confluence" и "Crowd".

Для обеспечения работы "Atlassian Jira/Jira-SD/Confluence/Crowd" нам потребуется следующий минимальный набор приложений:

1. "Oracle/Sun JDK/JRE v1.8+" ("Jira" не поддерживает пока "OpenJDK");
2. СУБД "PostgreSQL 9.x";
3. Фронтальный web-прокси "Nginx".

Учитывая то, что в Апреля 2019-го лицензионное соглашение "Oracle/Sun JDK/JRE" требует денег за коммерческое использование, я пробовал перейти на "OpenJDK" и столкнулся с проблемами совместимости - для работы "Atlassian Jira/Jira-SD" требуется java-класс "sun.awt.X11FontManager", отсутствующий в "OpenJDK" - пришлось пока остаться с "Oracle Java".

Приложения мы будем запускать в docker-контейнерах, а данные хранить на несущем сервере.

Сервер приложений "Tomcat v8" уже встроен в дистрибутив всех развёртываемых здесь продуктов "Atlassian" - так что его инсталлировать не нужно (WAR-версии web-приложений отдельно более не поставляются).

Последовательность дальнейших действий такова:

1. Подготовка системного окружения и установка сопутствующего ПО;
2. Установка и настройка фронтального web-прокси "Nginx";
3. Установка сервера СУБД "PostgreSQL" и создание "баз данных";
4. Создание для web-приложений "Atlassian" специфичных docker-контейнеров;
5. Подготовка конфигурации и пробные запуски web-приложений;
6. Формирование YAML-конфигурации "Docker Compose";
7. Миграция данных из уже работающих инстансов.

   [ уже посетило: 173 ]   [ просмотреть в полном объеме ]


Webhook + FCGI + Bash + Git  →   ( Дополнение к возможностям сервиса автоматизации доставки и развёртывания кода простейших web-приложений. )

10 июня 2019

OS: "Linux Debian 8/9", "Linux Ubuntu 16/18 LTS".
Apps: "Bash".

Здесь изложены необходимые для поддержки вызова внешнего приложения (в примере описывается связка с "Docker + Bash") дополнения к возможностям сервиса автоматизации доставки и развёртывания кода простейших web-приложений к серверам тестирования и публикации, рассматриваемого в вышестоящей заметке.

   [ уже посетило: 180 ]   [ просмотреть в полном объеме ]


Docker + Bash  →   ( Подготовка системного и прикладного окружения для площадки развёртывания тестовых стендов на базе "Docker". )

4 мая 2019

OS: "Linux Debian 9 (Stretch)", "Linux Ubuntu 18.04 LTS (Bionic Beaver)".
Apps: "Bash", "Docker" & etc.

В этой заметке описывается первый из этапов реализации поставленной в вышестоящей публикации задачи автоматизации процедур развёртывания тестовых стендов из docker-контейнеров.

Последовательность дальнейших действий:

1. Подготовка системного окружения.
2. Обеспечение доступа к файловым ресурсам разработчикам web-сайтов.
3. Обеспечение доступа к внешним файловым ресурсам посредством SSH.
4. Установка системы контейнеризации приложений "Docker".
5. Подготовка специализированного docker-образа для фронтального web-прокси.
6. Подготовка docker-образов с PHP-интерпретаторами разных версий.
7. Подготовка docker-образа для запуска NodeJS-приложений.
8. Подготовка конфигурационных файлов контейнеризируемых сервисов.
9. Автоматизация.

   [ уже посетило: 411 ]   [ просмотреть в полном объеме ]


DevOps  →   ( Сборка площадки развёртывания тестовых стендов для простейшей проверки функциональности web-сайтов, работающих на стеке из приложений "Nginx + PHP + NodeJS + Memcached + MySQL". )

4 мая 2019

OS: "Linux Debian 9 (Stretch)", "Linux Ubuntu 18.04 LTS (Bionic Beaver)".
Apps: "Bash", "Docker" & etc.

Задача: автоматизировать процедуры развёртывания тестовых стендов для простейшей проверки функциональности web-сайтов, работающих на стеке из приложений "Nginx + PHP + NodeJS + Memcached + MySQL". Практически описываемая схема эксплуатировалась в процессе разработки сайтов, которые публиковались посредством web-серверов, сделанных следуя инструкции по сборке и развёртыванию "LNPMM + Multisite" на этом же сайте.

Ради интереса я пробовал сделать схему тестирования с помощью "Docker Compose". В начале возможность описать конфигурацию в одном YAML-файле выглядела заманчиво, но с ростом сложности необходимость генерирования неопределённого количества отличающихся конфигураций, компоновки их, подсовывания "композеру", отслеживания результатов выполнения операций, изменения конфигураций и повторения предыдущих процедур свела на нет преимущества этой технологической прослойки для тестовой площадки - оказалось эффективнее пошагово собирать нужную схему, с поэтапным контролем запуска компонентов.

Особо отмечаю - здесь опубликована по сути лабораторная работа процесса познания малой толики того, что уже имеется в "Kubernetes"!

Последовательность дальнейших действий:

1. Подготовка несущего сервера docker-контейнеризации.
2. Создание конфигурационного файла тестового стенда (одного из неограниченного множества).
3. Написание скриптов развёртывания тестовых стендов и последующего ими управления.
4. Примеры использования развёрнутым сервисом.
5. Автоматизация запуска фронтальной точки приёма подключений извне.

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

   [ уже посетило: 247 ]   [ просмотреть в полном объеме ]


DevOps  →   ( Автоматизация процедур доставки кода, сборки Java-проекта и развёртывания web-приложений между серверами разработки, тестирования и публикации на примере "DSpace". )

4 апреля 2019

OS: "Linux Debian 9 (Stretch)", "Linux Ubuntu 18.04.1 LTS (Bionic Beaver)".
Apps: "RSync", "Netcat", SSH, "GitLab Runner", Bash.

Задача: наладить автоматизированные процедуры доставки кода, сборки Java-проекта и развёртывания web-приложений между серверами разработки, тестирования и публикации на примере поддержки сервиса репозитория цифровых документов "DSpace", считая последний установленным строго следуя инструкции по сборке и развёртыванию "DSpace v6" на этом же сайте.

В качестве Git-репозитория хранения и организатора процедур CI/CD (Continuous Integration/Deployment) для этой простейшей задачи подходит "GitLab CE (Community Edition)" - функционал его "pipelines" с описываемой в ".gitlab-ci.yml" логикой вполне достаточен.

Исходим из того, что процесс разработки ведётся по классической простейшей схеме перехода от ветке к ветке: "feature" -> "develop" -> "testing" -> "master". В нашем случае с использованием в качестве основы стороннего репозитория (практически замороженного) добавляется исходная ветвь "dspace-6_x".

   [ уже посетило: 409 ]   [ просмотреть в полном объеме ]


DevOps  →   ( Обходное решение проблемы с невозможностью повторного подключения "runner"-а к серверу "GitLab". )

2 апреля 2019

OS: "Linux Ubuntu 18.04.1 LTS (Bionic Beaver)".
Apps: "GitLab Runner v10.1+ (до v10.5 точно)".

Задача: решить проблему с невозможностью повторного, в рамках сеанса, подключения "runner"-а к серверу "GitLab".

   [ уже посетило: 310 ]   [ просмотреть в полном объеме ]


DevOps  →   ( Простая пошаговая настройка Git-репозитория на сервере хранения "GitLab", ориентированная на некоторые положения методики управления данными. )

20 марта 2019

Apps: "GitLab Community Edition (Standalone) Server".

Задача: проработать простую пошаговую настройку Git-репозитория на сервере хранения "GitLab", ориентированную на следующие основные положения методики управления данными ("workflow"):

1. Репозиторий используется для хранения любого дерева веток, но подразумевается наличие как минимум трёх: "master", "testing" и "develop";
2. В "develop" и ответвлениях "feature" ведётся разработка - с ними можно делать что угодно;
3. Ветка "testing" по правам доступа аналогична "develop" - но выгрузка в неё запускает автоматизацию процедур тестирования;
4. Выгрузка в "master" напрямую запрещена - только вливание из "testing" с предварительным "pull request"-ом, который должен быть одобрен руководителем - после чего запускаются автоматизированные процедуры публикации.

   [ уже посетило: 350 ]   [ просмотреть в полном объеме ]


Bacula  →   ( Налаживаем отображение сведений об использовании "Bacula" ресурсов, включая детали статусов заданий и томов данных, посредством web-интерфейса. )

12 февраля 2019

OS: "Linux Debian 9 (Stretch)".
Application: Bacula, Nginx, PHP-FPM.

Задача: наладить отображение сведений об использовании ресурсов системой резервного копирования "Bacula", включая детальные данные о статусе заданий и томов данных, посредством web-интерфейса.

"Bacula" довольно таки специфичный продукт, слегка подзастрявший где-то между любительской разработкой энтузиастов командной строки Linux и системы корпоративного уровня, отчего в базовой поставке всё управление реализовано через конфигурационные файлы и специализированную CLI-консоль. Графических интерфейсов почти нет, они зачаточны или предоставляются только для коммерческих поставок, как "BWeb Management Suite", например. Среди бесплатных вариантов на мой взгляд выбор ограничен двумя: "Bacula-Web" и "Webacula". Первый продукт приятнее, но умеет только собирать статистику. Второй корявее, но посредством его web-инерфейса возможен запуск задач восстановления. Продвигаемый самими разработчиками системы резервного копирования "Baculum" на мой вкус стилистически убог неприемлемо. Остальные проекты мелкие и малофункциональные.

Я использую в работе "Bacula-Web" - инструмент исключительно для отображения статистической информации, абсолютно без возможности воздействия на конфигурацию сервиса резервного копирования:

размер: 320 400 640 800 1024 1280
Bacula-Web: пример интерфейса web-сервиса отображения состояния системы резервного копирования "Bacula".
1570x876 • Bacula-Web: пример интерфейса web-сервиса отображения состояния системы резервного копирования "Bacula".

Я знаю, что "Webacula" поддерживает возможность запуска задач, в том числе и типа "Restore", посредством web-интерфейса - но моя принципиальная позиция в этом вопросе сводится к тому, что процедуры извлечения и восстановления данных имеют комплексный характер, непростые ввиду необходимости учитывать взаимосвязи нескольких сервисов и должны исполнятся специалистом своего дела, отлично владеющим CLI-инструментарием "Bacula".

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

   [ уже посетило: 623 ]   [ просмотреть в полном объеме ]


← Ctrl → Старее →
62  61  60  59  58  57  56  55  54  53  ...  Первая →