В этом уроке мы увидим, как мы можем использовать комментарии в Jenkinsfile . Мы рассмотрим различные типы комментариев и их синтаксис.
JenkinsfileСинтаксис Jenkinsfile основан на Groovy, поэтому для комментариев можно использовать синтаксис Groovy . Давайте возьмем простой пример Pipeline Linter и попробуем его закомментировать.
В этом руководстве мы рассмотрим, как запускать и останавливать сервер приложений JBoss.
Во-первых, мы изучим режимы работы этого сервера. Далее мы обсудим, как запускать и останавливать сервер в каждом из этих режимов работы.
JBoss — это сервер приложений с открытым исходным кодом, разработанный RedHat и теперь известный как WildFly. Мы можем скачать его с официального сайта WildFly .
Мы можем работать с этим сервером в двух разных режимах. Однако ключевое различие между этими режимами заключается в управлении сервером.
Веб-приложения — один из самых популярных вариантов использования Java. Веб-серверы и контейнеры сервлетов обеспечивают среду выполнения для развертывания приложений.
К сожалению, развертывание и устранение неполадок веб-приложений на веб-серверах иногда бывает сложным. К счастью, IDE имеют хорошую поддержку отладки для большинства приложений. Однако для отладки веб-приложений нам необходимо встроить веб-сервер в IDE.
В этом руководстве мы встроим Jetty в Eclipse, запустим и отладим на нем приложение .
Когда мы докеризовываем наши приложения, нам обычно нужно открыть один порт. Приложение использует этот порт для взаимодействия с другими контейнерами или внешним миром. Иногда одного порта недостаточно. Для других целей может потребоваться один или несколько дополнительных портов. Например, в приложении Spring Boot нам нужен отдельный порт для публикации конечных точек управления для мониторинга приложения с помощью привода.
В этой статье мы увидим, как объявить несколько открытых портов и как связать открытые порты с портами хост-компьютера , чтобы добиться вышеуказанного.
Во-первых, нам нужно объявить порты открытыми. Мы можем сделать это при создании образа докера. Также возможно объявлять порты при запуске контейнера на основе образа. Давайте посмотрим, как мы это делаем.
В этом руководстве мы продолжим изучение Java Kubernetes API. На этот раз мы покажем, как использовать часы для эффективного мониторинга событий кластера.
В наших предыдущих статьях, посвященных Kubernetes API , мы показали, как восстановить информацию о заданном ресурсе или их наборе. Это нормально, если все, что нам нужно, — это получить состояние этих ресурсов в определенный момент времени. Однако, учитывая, что кластеры Kubernetes очень динамичны по своей природе, этого обычно недостаточно.
Чаще всего мы также хотим отслеживать эти ресурсы и отслеживать события по мере их возникновения . Например, нас может заинтересовать отслеживание событий жизненного цикла модуля или изменений состояния развертывания. Хотя мы могли бы использовать опрос, этот подход имел бы несколько ограничений. Во-первых, это не будет хорошо масштабироваться по мере увеличения количества ресурсов для мониторинга. Во-вторых, мы рискуем потерять события, происходящие между циклами опроса.
Веб-приложения Spring Boot по умолчанию включают предварительно настроенный встроенный веб-сервер. Однако в некоторых ситуациях мы хотели бы изменить конфигурацию по умолчанию, чтобы она соответствовала индивидуальным требованиям.
В этом руководстве мы рассмотрим несколько распространенных вариантов настройки встроенного сервера Tomcat с помощью файла application.properties .
В этом руководстве мы рассмотрим операции CRUD с ресурсами Kubernetes с использованием официального Java API.
Мы уже рассмотрели основы использования этого API в предыдущих статьях, включая базовую настройку проекта и различные способы его использования для получения информации о работающем кластере.
Как правило, развертывания Kubernetes в основном статичны. Мы создаем некоторые артефакты (например, файлы YAML), описывающие то, что мы хотим создать, и отправляем их в конвейер DevOps. Затем части нашей системы остаются неизменными, пока мы не добавим новый компонент или не обновим существующий.
Однако бывают случаи, когда нам нужно добавлять ресурсы на лету. Распространенным является запуск заданий в ответ на запрос, инициированный пользователем. В ответ приложение запускало фоновое задание для обработки отчета и делало его доступным для последующего извлечения.
Ключевым моментом здесь является то, что, используя эти API, мы можем лучше использовать доступную инфраструктуру, поскольку мы можем потреблять ресурсы только тогда, когда они необходимы, а затем освобождать их.
При работе с докер-контейнером нам часто приходится запускать его в интерактивном режиме. Здесь мы присоединяем стандартный ввод, вывод или потоки ошибок нашего терминала к контейнеру.
Часто мы предпочитаем запускать наш контейнер в фоновом режиме. Однако мы можем захотеть подключиться к нему позже, чтобы проверить его вывод или ошибки, или отключить сеанс.
В этой короткой статье мы познакомимся с некоторыми полезными командами для достижения этих целей. Мы также увидим различные способы отключения от сеанса без остановки контейнера.
В Docker важно знать, какие порты прослушивает контейнерное приложение. Нам также нужен способ доступа к приложению из-за пределов контейнера.
Чтобы решить эти проблемы, Docker позволяет нам открывать и публиковать порты.
В этой статье мы узнаем как об открытии, так и о публикации портов. В качестве примера мы будем использовать простой контейнер веб-сервера Nginx.
В этом руководстве мы рассмотрим способы изменения уровня ведения журнала приложения Spring Boot во время выполнения. Как и многие другие вещи, Spring Boot имеет встроенную функцию ведения журнала , которая настраивает ее для нас. Мы собираемся изучить, как настроить уровни ведения журнала работающего приложения.
Мы рассмотрим три способа сделать это: с помощью конечной точки регистраторов Spring Boot Actuator , функции автоматического сканирования в Logback и, наконец, с помощью инструмента Spring Boot Admin .
Мы собираемся начать с использования конечной точки / loggers Actuator для отображения и изменения нашего уровня ведения журнала. Конечная точка / loggers доступна по адресу act/loggers , и мы можем получить доступ к конкретному регистратору, добавив его имя как часть пути.