Начнём пожалуй, со структуры, в которой всё будет:

docker/ docker-compose.yml .env .env.example .gitignore services     database      dump      .gitignore     nginx      site.conf     php         Dockerfile         php.ini

А теперь обо всём по порядку:

Файл .gitingore содержит только одну строчку /.env

Файл .env.example в начале проекта такой же, как и .env

В файле docker-compose.yml содержится информация про все наши сервисы:

version: "3.7"services:  php:    build:      args:        uname: ${PHP_UNAME}        uid: ${PHP_UID}        gid: ${PHP_GID}      context: ./services/php    container_name: ${PROJECT_NAME}_php    image: ${PROJECT_NAME}_php    restart: unless-stopped    working_dir: /var/www/    volumes:      - ./services/php/php.ini:/usr/local/etc/php/php.ini      - ../:/var/www    environment:      COMPOSER_MEMORY_LIMIT: 2G      XDEBUG_CONFIG: client_host=${XDEBUG_REMOTE_HOST} client_port=${XDEBUG_STORM_PORT} remote_enable=1      PHP_IDE_CONFIG: serverName=${XDEBUG_STORM_SERVER_NAME}    networks:      - main_network    depends_on:      - db  db:    image: mysql:5.6    restart: unless-stopped    container_name: ${PROJECT_NAME}_db    command: --default-authentication-plugin=mysql_native_password    environment:      MYSQL_DATABASE: ${DB_DATABASE}      MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}      MYSQL_PASSWORD: ${DB_PASSWORD}      MYSQL_USER: ${DB_USERNAME}    ports:      - ${DB_LOCAL_PORT}:3306    volumes:      - ./services/database/dump:/var/lib/mysql    networks:      - main_network  nginx:    image: nginx:1.17-alpine    restart: unless-stopped    container_name: ${PROJECT_NAME}_nginx    ports:      - ${NGINX_LOCAL_PORT}:80    volumes:      - ../:/var/www      - ./services/nginx:/etc/nginx/conf.d    networks:      - main_network    depends_on:      - phpnetworks:  main_network:    driver: bridge    name: ${PROJECT_NAME}_main_network    ipam:      driver: default      config:        - subnet: ${SUBNET_IP}/${SUBNET_MASK}

Из важного здесь стоит отметить ./services/php/php.ini:/usr/local/etc/php/php.ini - наш локальный файл php.ini (там некоторые конфиги дебаггера) будет намаплен на тот что внутри контейнера. XDEBUG_CONFIG - будет задана переменная окружения внутри контейнера php, которую потом будет испльзовать xdebug вместо значений по-умолчанию. Здесь мы задаем client_host - хост, к которому xdebug будет пытаться подключиться при инициации отладочного соединения. Этот адрес должен быть адресом машины, на которой ваш PhpStorm прослушивает входящие отладочные соединения. Получается так, что наша локальная машина находится в одной подсети с запущеными контейнерами, а её адресс будет первым в этой подсети. Таким образом, мы всегда можем знать каким будет адресс нашей машины, и позже зададим это значение в переменную XDEBUG_REMOTE_HOST . В CLIENT_PORT нужно будет задать порт, установленный на прослушивание в IDE (9003). XDEBUG_STORM_SERVER_NAME - имя сервера, который мы создадим в IDE позже. Этот параметр нужен, чтобы сообщить PhpStorm, как сопоставлять пути при подключении с докера (ведь у вас же открыты локальные файлы в редакторе, а код работает на удалённых; хотя при испльзовании volumes это не совсем так).

Вот, как выглядит файл окружения .env :

PROJECT_NAME=my_projectDB_DATABASE=my_project_dbDB_USERNAME=my_projectDB_PASSWORD=p@$$w0rdDB_ROOT_PASSWORD=toorPHP_UNAME=devPHP_UID=1000PHP_GID=1000DB_LOCAL_PORT=3377NGINX_LOCAL_PORT=8077XDEBUG_STORM_SERVER_NAME=DockerXDEBUG_REMOTE_HOST=192.168.227.1XDEBUG_STORM_PORT=9003SUBNET_IP=192.168.227.0SUBNET_MASK=28

На счёт подсети для проекта, то здесь мы задали 192.168.227.0 с маской 28, то-есть для всех устройств остаётся 32 - 28 = 4 бита, что равносильно 2 ** 4 - 1 = 15 контейнеров. Не 16 потому что в подсеть входит также наша локальная машина, которая, кстати, будет иметь адресс 192.168.227.1. Именно это значение мы задали в переменную XDEBUG_REMOTE_HOST.

Настройки веб-сервера site.conf:

server {    listen 80;    server_name 127.0.0.1 localhost;    client_max_body_size 5m;    error_log  /var/log/nginx/error.log;    access_log /var/log/nginx/access.log;    root /var/www/public;    index index.php;    location / {        try_files $uri $uri/ /index.php?$query_string;        gzip_static on;    }    location ~ \.php$ {        try_files $uri =404;        fastcgi_split_path_info ^(.+\.php)(/.+)$;        fastcgi_pass php:9000;        fastcgi_index index.php;        include fastcgi_params;        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;        fastcgi_param PATH_INFO $fastcgi_path_info;    }}

В нашем Dockerfile (тот что для php) нужно не забыть установить и включить xdebug. Для этого добавляем 2 строчки:

RUN pecl install xdebugRUN docker-php-ext-enable xdebug

Стоит отметить, что будет испльзована последняя (то-есть 3) версия (есть различия в конфигурации по сравнению с 2).

Полный Dockerfile:

FROM php:7.4-fpm# Arguments defined in docker-compose.ymlARG unameARG gidARG uid# Install system dependenciesRUN apt-get update \    && apt-get install -y \        git \        curl \        dpkg-dev \        libpng-dev \        libjpeg-dev \        libonig-dev \        libxml2-dev \        libpq-dev \        libzip-dev \        zip \        unzip \        cronRUN pecl install xdebugRUN docker-php-ext-enable xdebugRUN docker-php-ext-configure gd \  --enable-gd \  --with-jpegADD ./php.ini /usr/local/etc/php/php.ini# Clear cacheRUN apt-get clean && rm -rf /var/lib/apt/lists/*# Install PHP extensionsRUN docker-php-ext-install pdo pdo_mysql pdo_pgsql pgsql mbstring exif pcntl bcmath gd sockets zip# Get latest ComposerCOPY --from=composer:latest /usr/bin/composer /usr/bin/composer# Create system user to run Composer and Artisan CommandsRUN groupadd --gid $gid $unameRUN useradd -G www-data,root -s /bin/bash --uid $uid --gid $gid $unameRUN mkdir -p /home/$uname/.composer && \    chown -R $uname:$uname /home/$uname# Set working directoryWORKDIR /var/wwwUSER $uname# Expose port 9000 and start php-fpm serverEXPOSE 9000CMD ["php-fpm"]

Также, зададим некоторые параметры исплнения в php.ini :

max_execution_time=1000max_input_time=1000xdebug.mode=debugxdebug.log="/var/www/xdebug.log"xdebug.remote_enable=1

Запустим наше приложение:

docker-compose up -d

И дальше пойдём в PhpStorm для настройки:

Создадим сервер с названием Docker и cделаем маппинг локального корня проекта (/var/www/quizzy.loc) на путь, по которому он лежит в докере (/var/www):

Дальше, нам нужно будет настроить использование интерпретатора php из докера:

Теперь можем перейти в подпункт "Debug" и настроить порт на котором запускать:

Проверим, работает ли Xdebug:

Теперь можем поставить брейкпоинт в нашем коде и начать прослушивание входящих подключений:

Переходим в наш любимый браузер Firefox, устанавливаем и включаем плагин на нужной странице:

Перезагружаем страницу, и в PhpStrom должен поймать подключение:

Вступление. Краткая история и особенности языка.

Как-то давно мы с моим товарищем и коллегой Егором готовили обучающий курс по Java Core. Но как-то не срослось и это дело не было доведено до какого-либо логического конца. И вот, спустя время, я решил, что не стоит пропадать добру и по-этому запускаю серию статей про Java Core для самых маленьких.

Начало разработки языка было положено еще в 1991 году компанией Sun Microsystems, Inc. Вначале язык был назван Oak (Дуб), но в 1995 он был переименован в Java. Публично заявили о создании языка в 1995 году. Причиной создания была потребность в независящем от платформы и архитектуры процессора языке, который можно было бы использовать для написания программ для бытовой электротехники. Но поскольку в таких устройствах применялись различные процессоры, то использование популярных на то время языков С/С++ и прочих было затруднено, поскольку написанные на них программы должны компилироваться отдельно для конкретной платформы.

Особенностью Java, которая решила эту проблему, стало то, что компилятор Java выдает не машинный исполняемый код, а байт-код - оптимизированный набор инструкций, которые выполняются в так называемой виртуальной машин Java (JVM - Java Virtual Machine). А на соответствующую платформу предварительно устанавливается JVM с необходимой реализацией, способная правильно интерпретировать один и тот же байт-код. У такого подхода есть и слабые стороны, такие программы выполняются медленнее, чем если бы они были скомпилированы в исполняемый код.

Установка программного обеспечения - JDK

В первую очередь, нам нужно установить на компьютер так называемую JDK (Java Development Kit) - это установочный комплект разработчика, который содержит в себе компилятор для этого языка и стандартные библиотеки, а виртуальную машинуJava (JVM) для вашей ОС.

Для того чтобы скачать и установить JDK открываем браузер, и в строке поиска Google вводим download JDK или переходим по этой ссылке.

Скролим ниже и находим таблицу с вариантами скачивания JDK. В зависимости от нашей операционной системы выбираем файл для скачивания.

Процесс установки для ОС Windows имеет несколько этапов. Не стоит пугаться, все очень просто и делается в несколько кликов. Вот здесь подробно описан процесс установки. Самое важное для пользователей Windows это добавить системную переменную JAVA_HOME. В этой же статье достаточно подробно расписано как это сделать (есть даже картинки).

Для пользователей MacOS также стоит добавить переменную JAVA_HOME. Делается это следующим образом. После установки .dmg файла JDK переходим в корневую папку текущего пользователя и находим файл .bash_profile. Если у вас уже стоит zsh то ищем файл .zshenv. Открываем этот файл на редактирование и добавляем следующие строки:

export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_271.jdk/Contents/Homeexport PATH=${PATH}:${JAVA_HOME}

Здесь обратите внимание на версию JDK указанную в пути - jdk1.8.0_271.jdk. Могу предположить, что у вас она будет отличаться, поэтому пройдите по указанному пути и укажите свою версию. Сохраняем изменения и закрываем файл, он нам больше не понадобится.

Теперь важно проверить правильность установки JDK. Для этого открываем командную строку, в случае работы на Windows, или терминал для MacOS. Вводим следующую команду: java -version Если вы все сделали правильно, вы увидите версию установленного JDK. В ином случае вы, скорее всего, допустили где-то ошибку. Советую внимательно пройтись по всем этапам установки.

Установка IDE

Теперь нам нужно установить среду разработки, она же IDE (Integrated development environment). Что собой представляет среда разработки? На самом деле она выглядит как текстовый редактор, в котором мы можем вводить и редактировать текст. Но помимо этого, этот текстовый редактор умеет делать проверку синтаксиса языка на котором вы пишете. Делается это для того чтобы на раннем этапе подсказать вам о том, что вы допустили ошибку в своем коде.

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

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

Для начала нам нужно выбрать и среду разработки. Их довольно таки много, и самыми популярными из них являются: IntelliJ IDEA, NetBeans, Eclipse. Для себя я выбираю IntelliJ IDEA. Она является самой удобной на мой взгляд, и хоть она и платная, на официальном сайте можно найти бесплатную версию которая называется Community. Этой версии будет вполне достаточно для изучения основ Java. Вообщем будем работать в IntelliJ IDEA.

Итак, открываем браузер, в поисковой строке вводим "Download IntelliJ IDEA Community" или переходим по этой ссылке. Выбираем версию ОС и качаем версию Community.

В установке IntelliJ IDEA нет ничего военного. На крайний случай на ютубе есть множество видео о том, как установить эту программу.

Первая программа

Теперь мы готовы создать нашу первую программу. В окошке запустившийся IDE нажимаем New Project.

В новом окошке в левой панели выбираем Java.

Обратите внимание! В верхнем окошке, справа, возле надписи "Project SDK:" должна находится версия Java, которую вы установили вместе с JDK. Если там пусто, то вам нужно будет указать путь к вашему JDK вручную. Для этого в выпадающем списке нажмите "Add JDK..." и укажите путь к вашему JDK, который был предварительно установлен.

Теперь можем нажать на кнопку Next. В следующем окошке, вверху, поставьте галочку Create project from template и выберите Command Line App. И снова нажимаем Next.

Дальше нам нужно указать имя программы. У меня это будет Hello World, желательно чтобы имя проекта было введено латиницей, и на английском языке.

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

После указываем путь к проекту программы.

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

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

Это окно, то что вы будете видеть 80-90%, а иногда и 100% времени, работая программистом.

Для того чтобы закончить ваше первое приложение, останется добавить строчку кода System.out.print("Hello world!"); как показано на скриншоте.

Чтобы скомпилировать и запустить на выполнение вашу программу, вам нужно нажать кнопочку с зеленым треугольничком на верхней панели справа, или в меню найти пункт Run -> Run Main. И внизу на нижней панели, под окном редактора, в консоли, вы увидите результат выполнения вашей программы. Вы увидите надпись Hello World! Поздравляю, вы написали свою первую программу на Java.

Разбираем первую программу

В своем первом приложении вы можете увидеть много непонятных символов и слов, но на данном этапе вы должны воспринять их как данность, позже, в следующих частях, я расскажу о каждом из них, и зачем они нужны. На данном этапе вам нужно понять что это стандартные составляющие любого Java-приложения, и в последующих приложениях эти компоненты будут изменяться минимально.

Пройдемся по порядку:

В начале мы видим package com.zephyr.ventum; - это объявление пакета, и это постоянный атрибут файлов с исходным кодом в Java. Простыми словами, это локация вашего файла в проекте и любой .java файл должен начинаться с подобной строки.

Ниже, public class Main { - это стандартное объявление класса в Java, где public - это модификатор доступа который дает программисту возможность управлять видимостью членов класса, class - является ключевым словом объявляющим класс, Main - это имя класса. Все определение класса и его членов должно располагаться между фигурными скобками { }. Классы мы рассмотрим немного позже, только скажу что в Java все действия программы выполняются только в пределах класса.

Ключевое слово - это слово зарезервированное языком программирования. Например, package - это тоже ключевое слово.

Еще ниже, public static void main(String[] args) { - эта строка является объявлением метода main. Метод (или часто говорят функция) main это точка входа в любой java-программер. Именно отсюда начинается выполнение вашего кода. В проекте может быть несколько методов main, но мы должны выбрать какой-то один для запуска нашей программы. В следующих статьях мы еще вернемся к этому. Сейчас же у нас только один метод main.

Фигурные скобки {} у метода main обозначаю начало и конец тела метода, весь код метода должен располагаться между этими скобками. Аналогичные скобки есть и у класса Main.

Следующая строка является // write your code here однострочным комментарием.

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

Многострочный комментарий будет выглядеть следующим образом:

/* write  your  code here */

Мы просто располагаем несколько строк между символами /* и */

System.out.print("Hello world!"); - строка которая находится внутри метода main является командой, которая выводит в консоль строку "Hello world!"

Обратите внимание что в конце стоит точка с запятой, в языке Java команды должны заканчиваться точкой с запятой.

Затем мы закрываем тело нашего метода main } а также закрываем класс Main }.

На этом статья подходит к концу. Автором конкретно этого материала является Егор и все уменьшительно ласкательные формы слов сохранились в первозданном виде.

В следующей статье мы поговорим о типах данных в Java.

В преддверии старта Экспресс-курса IaC Ansible делимся с вами переводом материала.

Ansible это мощный инструмент ИТ-автоматизации и, аналогично другим подобным инструментам, его освоение требует времени.

Я использовал Ansible для автоматизации развертывания и управления корпоративными приложениями и извлек ряд уроков, с которыми хотел бы поделиться, чтобы помочь другим. В конце концов, это open source принцип.

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

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

Стандарты

Для автоматизации важны три вещи:

1. стандарты

2. стандарты и

3. ах да, стандарты!

Довольно просто написать небольшой плейбук для выполнения конкретной админской задачи. Но при разработке сотни плейбуков / ролей для автоматического развертывания целого программного стека в разных окружениях все становится довольно сложным. Кроме того, ваши плейбуки и роли будут усложняться, если вы не будете переиспользовать роли и не стандартизируете их. Начать изучение Ansible вы можете с этого туториала (англ.).

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

Далекая-далекая галактика

Ansible Galaxy, централизованный репозиторий ролей Ansible от сообщества ваш друг. Вам обязательно стоит посмотреть не решил ли уже кто-то другой вашу проблему.

Но будьте осторожны. Содержимое Galaxy использовать можно, но его следует внимательно изучить и разобраться, прежде чем размещать в своем окружении. Вы легко и быстро можете испортить себе жизнь, используя роль, которая делает что-то неожиданное.

Инвентори

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

Например, у нас было много XML-файлов, содержащих информацию о конфигурации нашего программного обеспечения. Мы создали шаблоны Jinja и перенесли конфигурацию из XML-файлов в Ansible Inventory. XML-файлы стало гораздо проще генерировать и деплоить на серверы. Кроме того, для работы с разными окружениями мы использовали специально созданный Vars Plugin, написанный на Python, загружающий только нужные данные конфигурации в инвентори.

Обработчики

Обработчики (handlers) это задачи, которые запускаются по событию. Только по событию и только один раз для плейбука. Например, вы можете настроить обработчики для такого события, как перезапуск сервиса или приложения. Использование обработчиков в роли, управляющей определенным сервисом, может быть отличным решением для создания ясных и понятных задач в файле handlers / main.yml, запускаемых при изменении сервиса.

Когда я начинал работать с Ansible, то обработчиков в нем еще не было. Так что я могу рассказать вам, какой была жизнь до и после этого не позволяйте этой возможности пропадать впустую!

Идемпотентность поймите ее, живите с ней, любите ее

Идемпотентность это образ жизни ИТ-автоматизации. Вам нужно понять ее, а затем при написании кода автоматизации жить в соответствии с ней. Так что же это такое? Процитирую глоссарий Ansible, операция "идемпотентна, если результат однократного применения операции такой же, как результат ее многократного применения".

То есть вы можете запускать свои плейбуки несколько раз, а конечный результат будет оставаться неизменным целевые серверы будут находится в "desired state". И если ваш плейбук не заработает, то вы можете устранить проблемы и запустить плейбук еще раз. Поскольку плейбук является идемпотентным, целевые серверы должны быть в "desired state", и никаких других изменений не произойдет.

Что в имени твоём?

Пожалуйста, пожалуйста, всегда давайте имена задачам. Это кажется глупым и похожим на просьбу комментировать код, но важно давать задачам ясные имена, чтобы всем было понятно, что она делает. Следуйте простым правилам:

1. Не пишите в плейбуках Ansible комментарии как при разработке программного обеспечения, например, "# это комментарий". Помните, Ansible это не язык программирования, это инструмент автоматизации.

2. Вместо этого для описания Play и Task используйте "Name" с понятным названием. Опишите свои намерения, но постарайтесь воздержаться от технических деталей.

Самая большая польза от свойства "Name" заключается в том, что оно отображается при запуске плейбука. Это помогает при диагностике. А комментарии не отображаются.

Мой опыт показывает, что плейбуки / роли / задачи пишутся разными людьми в компании (по крайней мере, командами Dev и Ops), и все должны понимать, что делает задача.

Именование и приоритет переменных

Будьте осторожны при именовании переменных в инвентори, плейбуках и ролях Ansible. Помните, что Ansible присваивает каждую переменную определенному хосту (Host Variables). Поэтому с осторожностью используйте общие имена, такие как "java_path: /my path". Есть вероятность, что другое приложение на том же хосте использует Java, но по другому пути. Часто на одном хосте могут размещаться несколько приложений, использующих разные версии Java, расположенные по разным путям.

Указывайте в переменных префикс, используя название вашей компании. Например, переменные приложения AppOne, созданного компанией ABC и использующее Java 1.8, могут выглядеть следующим образом:

abc_appone_java_path: "/opt/appone/java"abc_appone_java_version: "1.8"

Не копипастите

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

Используйте IDE

Используйте для Ansible какую-нибудь IDE. В конце концов, это просто YAML. IDE должна упрощать вам работу. Вот некоторые функции, которые я считаю критически важными для IDE при создании ролей и плейбуков Ansible:

• Подсветка синтаксиса YAML и поддержка линтеров.

• Подсветка синтаксиса Python и поддержка линтеров Ansible написан на Python, и, поверьте мне, вам иногда придется смотреть исходный код.

• Интеграция с системой контроля версий.

• Интеграция с JIRA возможность управлять изменениями сразу в нескольких тикетах.

• Удобные поиск и замена часто вам нужно будет изменять, удалять или перемещать какую-то переменную сразу в нескольких файлах.

• Поддержка Ruby если вы также собираетесь работать с Vagrant.

• Поддержка Groovy если вы собираетесь работать с заданиями Jenkins.

Эти советы помогут вам быть на шаг впереди и избежать тех ошибок, которые совершал я при использовании Ansible для развертывания и автоматизации корпоративного программного обеспечения. У вас будут свои новые и интересные ошибки! Для дополнительной информации о лучших практиках работы с Ansible смотрите раздел лучших в практик документации Ansible и скачайте чеклист по автоматизации, а также следите за блогами Red Hat и Ansible.

Узнать подробнее про Экспресс-курс IaC Ansible.

Перевод статьи How the Language Server Protocol Affects the Future of IDEs

Автор оригинала Mehul Mohan

С момента своего появления Visual Studio Code в одиночку так сильно повлиял на экосистему разработчиков, что возврата назад уже не будет. Это общедоступный бесплатный инструмент с открытым исходным кодом и это очень мощный инструмент.

Но, благодаря VSCode, Microsoft в 2016 году дала жизнь еще одной супер значимой вещи, которая менее известна. Это Language Server Protocol - Протокол языкового сервера.

Что такое Протокол языкового сервера?

Протокол языкового сервера (Language Server Protocol - LSP) - это способ общения с языковыми серверами (такой же как HTTP или FTP).

Языковые серверы - это специальные программы, работающие на обычных серверах. Они принимают мета-состояние редактора, в котором вы пишете код (например, текущая позиция курсора внутри редактора, токен над которым находится курсор), и возвращают набор действий или инструкций - какой токен должен быть следующим, что должно произойти, когда вы нажимаете CMD/Ctrl-клик на этом токене, и так далее.

Это взаимодействие происходит с помощью набора правил, заданных протоколом. Протокол языкового сервера можно рассматривать как урезанную модификацию HTTP взаимодействующую только по JSON-RPC протоколу.

Зачем нужен LSP?

Вы заметили, что в VSCode постоянно появляются изобретательные сообщения об общибках и предложения автоподстановок? И как же легко, просто установив расширение из магазина VSCode, вы получаете всю мощь IntelliSense для совершенно разных языков, таких как C, Python, Java и т.д.? Все это происходит благодаря LSP.

Поддержка автозавершения и IntelliSense для HTML/CSS/JavaScript идет сразу вместе с VSCode (так же, как PyCharm идет сразу с поддержкой Python). Однако такая же поддержка других языков может быть реализована с помощью протокола LSP для этих языков.

Что такое JSON-RPC?

JSON-RPC означает удаленный вызов процедуры JSON (Remote Procedure Call). Это архитектура (подобно тому, как REST является архитектурой), но основная единица - это вызов процедуры, а не конечная точка API в случае REST.

Это простой пример для JSON-RPC:

// Requestcurl -X POST data '{"jsonrpc": "2.0","method": "runThisFunction","params": [ "some-param", 2 ],"id": 1}'// Response{  "jsonrpc": "2.0",  "result": "codedamn",  "id": 1}

В этом примере мы посылаем запрос в кодировке JSON в соответствии со спецификацией RPC. Если сервер настроен на корректную работу с JSON-RPC, то он выполнит метод runThisFunction с переданными параметрами и вернет результат в том виде, как показано выше.

LSP + JSON-RPC

LSP использует JSON-RPC для связи с удаленным сервером. Для этого используется следующий формат:

Content-Length: <bytes of JSON>\r\n\r\n<json-payload>

Пример запроса:

Content-Length: 78{"jsonrpc":"2.0","method":"runThisFunction","params":["some-param",2],"id":1}

LSP требует, чтобы вы передали заголовок Content-Length, за которым следуют два CRLF токена \r\n. Когда запущенные языковые серверы, такие как ccls, получат это сообщение, они ответят соответствующим сообщением:

Конечно, в приведенном выше примере видно, что ccls говорит о том, что не существует метода, названного runThisFunction. Но можно заметить, что удаленный сервер также отвечает заголовком Content-Length со спецификацией JSON-RPC.

Почему все это так важно?

С введением формального протокола LSP, Microsoft свела знаменитую проблему M x N к проблеме M + N.

M = Различные языки (C, C++, PHP, Python, Node, Swift, Go и т.д.).

N = Различные редакторы кода (VSCode, Eclipse, Notepad++, Sublime Text и т.д.).

Раньше для того, чтобы M редакторов поддерживали N языков, вам нужно было иметь M*N решений. То есть каждый редактор кода должен был реализовать поддержку каждого языка самостоятельно.

С появлением LSP в редактор оставалось лишь внедрить поддержку протокола языкового сервера. После этого любой, кто делает языковой сервер (следуя стандартам LSP), может легко интегрироваться в редактор кода, при этом редактор никогда не будет "знать", с каким языком он работает!

Будущее IDE

По мере того, как языковые сервера реализуются для различных языков программирования, у разработчиков появляется возможность выбирать редактор на свой вкус. Без привязки к конкретному языку. Нет больше необходимости ограничивать себя, например только XCode для разработки на Swift или PyCharm для Python. И не только это, LSP можно внедрить прямо в JavaScript для поддержки IntelliSense в браузере! Настало потрясающее время для программистов!

Перевод статьи How the Language Server Protocol Affects the Future of IDEs

Автор оригинала Mehul Mohan

С момента своего появления Visual Studio Code в одиночку так сильно повлиял на экосистему разработчиков, что возврата назад уже не будет. Это общедоступный бесплатный инструмент с открытым исходным кодом и это очень мощный инструмент.

Но, благодаря VSCode, Microsoft в 2016 году дала жизнь еще одной супер значимой вещи, которая менее известна. Это Language Server Protocol - Протокол языкового сервера.

Что такое Протокол языкового сервера?

Протокол языкового сервера (Language Server Protocol - LSP) - это способ общения с языковыми серверами (такой же как HTTP или FTP).

Языковые серверы - это специальные программы, работающие на обычных серверах. Они принимают мета-состояние редактора, в котором вы пишете код (например, текущая позиция курсора внутри редактора, токен над которым находится курсор), и возвращают набор действий или инструкций - какой токен должен быть следующим, что должно произойти, когда вы нажимаете CMD/Ctrl-клик на этом токене, и так далее.

Это взаимодействие происходит с помощью набора правил, заданных протоколом. Протокол языкового сервера можно рассматривать как урезанную модификацию HTTP взаимодействующую только по JSON-RPC протоколу.

Зачем нужен LSP?

Вы заметили, что в VSCode постоянно появляются изобретательные сообщения об общибках и предложения автоподстановок? И как же легко, просто установив расширение из магазина VSCode, вы получаете всю мощь IntelliSense для совершенно разных языков, таких как C, Python, Java и т.д.? Все это происходит благодаря LSP.

Поддержка автозавершения и IntelliSense для HTML/CSS/JavaScript идет сразу вместе с VSCode (так же, как PyCharm идет сразу с поддержкой Python). Однако такая же поддержка других языков может быть реализована с помощью протокола LSP для этих языков.

Что такое JSON-RPC?

JSON-RPC означает удаленный вызов процедуры JSON (Remote Procedure Call). Это архитектура (подобно тому, как REST является архитектурой), но основная единица - это вызов процедуры, а не конечная точка API в случае REST.

Это простой пример для JSON-RPC:

// Requestcurl -X POST data '{"jsonrpc": "2.0","method": "runThisFunction","params": [ "some-param", 2 ],"id": 1}'// Response{  "jsonrpc": "2.0",  "result": "codedamn",  "id": 1}

В этом примере мы посылаем запрос в кодировке JSON в соответствии со спецификацией RPC. Если сервер настроен на корректную работу с JSON-RPC, то он выполнит метод runThisFunction с переданными параметрами и вернет результат в том виде, как показано выше.

LSP + JSON-RPC

LSP использует JSON-RPC для связи с удаленным сервером. Для этого используется следующий формат:

Content-Length: <bytes of JSON>\r\n\r\n<json-payload>

Пример запроса:

Content-Length: 78{"jsonrpc":"2.0","method":"runThisFunction","params":["some-param",2],"id":1}

LSP требует, чтобы вы передали заголовок Content-Length, за которым следуют два CRLF токена \r\n. Когда запущенные языковые серверы, такие как ccls, получат это сообщение, они ответят соответствующим сообщением:

Конечно, в приведенном выше примере видно, что ccls говорит о том, что не существует метода, названного runThisFunction. Но можно заметить, что удаленный сервер также отвечает заголовком Content-Length со спецификацией JSON-RPC.

Почему все это так важно?

С введением формального протокола LSP, Microsoft свела знаменитую проблему M x N к проблеме M + N.

M = Различные языки (C, C++, PHP, Python, Node, Swift, Go и т.д.).

N = Различные редакторы кода (VSCode, Eclipse, Notepad++, Sublime Text и т.д.).

Раньше для того, чтобы M редакторов поддерживали N языков, вам нужно было иметь M*N решений. То есть каждый редактор кода должен был реализовать поддержку каждого языка самостоятельно.

С появлением LSP в редактор оставалось лишь внедрить поддержку протокола языкового сервера. После этого любой, кто делает языковой сервер (следуя стандартам LSP), может легко интегрироваться в редактор кода, при этом редактор никогда не будет "знать", с каким языком он работает!

Будущее IDE

По мере того, как языковые сервера реализуются для различных языков программирования, у разработчиков появляется возможность выбирать редактор на свой вкус. Без привязки к конкретному языку. Нет больше необходимости ограничивать себя, например только XCode для разработки на Swift или PyCharm для Python. И не только это, LSP можно внедрить прямо в JavaScript для поддержки IntelliSense в браузере! Настало потрясающее время для программистов!

3 мая 2021 года Red Hat выпустила первую общедоступную версию OpenShift Pipelines, облачно-ориентированной системы непрерывной интеграции на базе СПО-проекта Tekton. Решение реализует Kubernetes фреймворк CI/CD для разработки и выполнения конвейеров, в которых каждый шаг запускается в своем собственном контейнере, что позволяет масштабировать шаги независимо друг от друга. Сегодня мы вкратце рассмотрим ключевые особенности и преимущества этого решения, а также приведем список дополнительных ресурсов для дальнейшего знакомства с ней и освоения.

Но, прежде чем переходить к OpenShift Pipelines, освежим в памяти основные концепты Tekton.

Основные концепты Kubernetes-нативной CI/CD

OpenShift Pipelines дополняет Kubernetes/OpenShift соответствующими CRD (ресурсами, определяемыми пользователем) для концептов CI/CD, таких как конвейер (pipeline), задача (task), шаг (step). В результате, эти концепты становятся своими (native) инстанцируемыми их можно создавать в виде отдельных экземпляров и, как следствие, полноценно масштабировать и развертывать, а также обеспечивать их безопасность средствами Kubernetes.

Поэтому для начала вспомним, что такое концепты Tekton:

По сути, основные концепты Tekton делятся на два вида: те, что задают конвейер, и те, что запускают конвейер.

Концепты, задающие конвейер (define pipeline)

• Task повторно используемые и слабо связанные серии шагов (step), которые выполняют определенную задачу, например, сборку контейнерного образа.

• Pipeline описание конвейера и задач (Task), которые он должен выполнять.

Концепты, запускающие конвейер (run pipelines)

• TaskRun запуск и результаты выполнения экземпляра Task.

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

Подробнее об этих концептах можно почитать в официальной документации.

Теперь разберемся, что такое OpenShift Pipelines и для чего он нужен

Что такого особенного в OpenShift Pipelines?

OpenShift Container Platform это ведущая отраслевая Kubernetes-платформа корпоративного класса, которая предоставляет разработчикам множество функций, среди которых есть и CI/CD.

OpenShift Pipelines базируется на СПО-проекте Tekton и расширяет функционал платформы OpenShift стандратными методами, что сильно облегчает жизнь разработчикам.

Установка OpenShift Pipelines через механизм Operator

OpenShift Pipelines поддерживается на уровне механизма операторов, поэтому он легко устанавливается и обновляется, и, соответственно, легко администрируется.

OpenShift Pipelines доступен на сайте OperatorHub, где представлены более 450 различных операторов для OpenShift Container Platform:

Установка OpenShift Pipelines предельно проста, и он сразу устанавливается как оператор уровня кластера, автоматически становясь доступным для всех проектов:

OpenShift Pipelines также дополняет OpenShift соответствующими CR, которые позволят добиться еще большей универсальности в плане конфигурации и интеграции с консолью OpenShift и т.д.

При появлении в OperatorHub новой версии OpenShift Pipelines, вы как администратор можете выбрать обновление до следующей версии, задав нужный канал обновления.

Развитый UI в рамках консоли OpenShift

Tekton тоже дополняет стандартную поставку OpenShift концептами CI/CD, но в нем при создании и запуске конвейеров сложно обойтись без создания YAML-кода, и этого кода требуется писать очень много, тысячи строк. Поэтому Red Hat реализовала в консоли OpenShift полноценный UI для запуска и визуализации конвейеров (как тех, что работают сейчас, так и тех, что уже отработали), а также для графического создания конвейеров. При этом все необходимые YAML-файлы создаются автоматически, без написания какого-либо кода.

Ниже показано графическое представление конвейера, который уже был выполнен на платформе OpenShift, причем прямо из него можно получить доступ к журналам и событиям всех задач этого конвейера:

При желании можно легко просмотреть полный лог выбранной задачи:

Чтобы еще больше облегчить жизнь разработчикам, OpenShift Pipelines позволяет рисовать конвейеры прямо в консоли OpenShift, поэтому вам больше не нужен черный пояс по YAML, чтобы создать свой первый конвейер Tekton:

Но если вы, как обладатель черного пояса по YAML, захотите что-то подправить, это всегда можно сделать прямо из консоли OpenShift:

Более того, OpenShift Pipelines пригодится, даже если вы решите пойти по пути чистого YAML, и предложит вам готовые примеры и снипеты кода для более быстрой разработки конвейеров YAML. Кроме того, в систему можно интегрировать ваши корпоративные снипеты, сделав их доступными всем разработчикам. Именно для этого мы и добавили специальный CRD под названием ConsoleYAMLSamples.

События как триггеры для запуска конвейеров

Хотите увязать запуск конвейеров с некими внешними событиями (в терминах Tekton это называется Trigger), например, push- или pull-запросами Github или Gitlab? Вообще не проблема, в OpenShift Pipelines это есть из коробки, причем поддерживаются различные вендоры, включая Github, Gitlab, BitBucket и т.д.

Вы просто создаете нужный триггер в UI, а OpenShift сам формирует все необходимые концепты, такие как EventListeners, TriggerTemplates (подробнее о них можно почитать в официальной документации).

Готовые повторно используемые задачи и кастомизация

OpenShift Pipelines из коробки содержит десятки готовых задач, которые можно использовать в составе конвейеров, включая задачи по клонированию кода из репозитория, сборки приложений на различных языках программирования, таких как java, dotnet core, python go, nodejs или использования инструментов сборки вроде maven, развертывания приложений и т.д. Список доступных задач можно увидеть в консоли OpenShift, раздел ClusterTasks, меню Pipelines -> Tasks:

Кроме того, этот список можно легко расширить. Для этого достаточно добавить ClusterTasks в кластер, после чего вам станут доступны сотни дополнительных задач на сайте TektonHub, который представляет собой публичный репозиторий для обмена задачами Tekton:

Интеграция с IDE

Разработчики, использующие командную строку и IDE, могут воспользоваться преимуществами Tekton CLI, расширения Tekton для Visual Studio Code и плагина Tekton для IntelliJ, чтобы взаимодействовать с конвейерами прямо из своей обычной среды разработки и создавать, запускать, просматривать и выполнять действия на кластере непосредственно из командной строки.

Полезные ресурсы

В заключение советуем посмотреть видеоверсию этой статьи на английском:

А также рекомендуем следующие ресурсы (EN):

• Запись в блоге Red Hat к выпуску первых общедоступных версий OpenShift Pipelines и OpenShift GitOps

• Cтраница продукта OpenShift Pipelines

• Документация OpenShift Pipelines

• Интерактивные руководства по работе с OpenShift Pipelines

• Демовидео от Siamak Sadeghianfar, продакт-менеджера OpenShift Pipelines

• Серия статей Guide to OpenShift Pipelines в блоге Red Hat OpenShift

Видеоролики на русском:

• Все необходимое за две минуты

• Подробно про Tekton (включая предыдущий ролик с озвучкой)

Вебинары:

• 1 июня. Red Hat Advanced Cluster Security Надежная защита облачных приложений
  На вебинаре рассмотрим инструментыRed Hat Advanced Cluster Security, необходимые для обеспечения безопасности облачных приложений. Эксперты Red Hat и BCC расскажут, как Advanced Cluster Security защищает жизненно важные приложения на протяжении всего процесса сборки, развертывания и выполнения. Устраняет слепые зоны в безопасности и сокращает время и усилия, необходимые для реализации максимального уровня безопасности, а также упрощает анализ, расследование и исправление в системе безопасности

• 17 июня.Установка и операции второго дня
  Расскажем про то, как ставитьOpenShiftс помощью Helper Node и еще немного про Day-2, а также проведеммастер-класс, на котором объясним, что стоит проделать после того, как OpenShift вошел в вашу жизнь.

• OpenShift Serverless (в записи)

• OpenShift Virtualization (в записи)

• Принципы Cloud native apps design (в записи)

• 10 уровней контейнерной безопасности(в записи)