Red hat codeready linux builder

Red Hat CodeReady Workspaces

Coding on Kubernetes

A collaborative Kubernetes-native solution for rapid application development that delivers consistent developer environments on Red Hat OpenShift to allow anyone with a browser to contribute code in under two minutes

The OpenShift-native developer workspace server and IDE

Built on the open Eclipse Che project, Red Hat CodeReady Workspaces uses Kubernetes and containers to provide any member of the development or IT team with a consistent, secure, and zero-configuration development environment. The experience is as fast and familiar as an integrated development environment on your laptop.

CodeReady Workspaces is included with your OpenShift subscription and is available in the Operator Hub. It provides development teams a faster and more reliable foundation on which to work, and it gives operations centralized control and peace of mind.

Get coding today with our free Developer Sandbox for Red Hat OpenShift, which includes CodeReady Workspaces to try out at no cost.

Modern development workflow

OpenShift-native development

Developers can focus more on coding, with their application and development environment containerized and running on OpenShift — all without needing to understand the details of Kubernetes. Administrators can easily manage and monitor workspaces as any other Kubernetes resource.

In-browser IDE

CodeReady Workspaces includes a powerful and familiar in-browser IDE with support for Microsoft Visual Studio Code extensions. Developers need only a machine capable of running a web browser to code, build, test, and run on OpenShift.

Consistent one-click developer workspaces

Workspaces are centrally configured, easily shareable, and are consistent to
remove «works on my machine» issues. A workspace includes:

• Resource allocation
• Project source code repositories
• Application runtimes
• Build tools
• Development tools: Browser-based editor and plug-ins

Near instant onboarding

Anyone with a browser can start contributing to a project within two minutes–it’s not just a core development team that can benefit and contribute.Integration with the Red Hat OpenShift Developer Console also allows you to launch a workspace for an application directly from the Topology view.

Enterprise integration

The entire development workspace and source code access are secured using the same access tools used across the rest of the organization.

Includes Red Hat SSO to handle authentication and security between the developer teams. Allows integration with LDAP or AD.

Inner loop made easy

Developers can run their application, view live-updates a preview pane as they code, and share with colleagues and stakeholders by easily exposing a route.

Broad set of certified stacks

Developers can leverage the bundled high-grade, certified container images for popular stacks as the base for their enterprise-grade applications.

Источник

Introducing CodeReady Linux Builder

The RHEL 8 introduces a new repository, the CodeReady Linux Builder (or “Builder” for short) that developers may need while developing applications for RHEL. As you all know “developer” is not a one size fits all term. As a result, I am taking this opportunity to try to explain when you might need Builder enabled for your development activities.

First off, if you are a typical web developer, dealing with PHP, Ruby, or Perl you are unlikely to need the content delivered through Builder. The PHP packages, Ruby gems, and Perl modules provided in the AppStream repository will, in most cases, provide sufficient functionality to develop and run applications you create yourself and to run frameworks like Drupal, WordPress, Rails, or Twiki. Please see the appropriate HowTos for getting these things up and running.

Ruby and Perl both have additional libraries made available in the Builder repository. However, they are less commonly used or used at build time only.

Next we have Java developers. Again, much of the functionality and jars you would expect to use normally have been provided in the AppStream. For example ant, maven and apache-commons-logging can be found directly in AppStream. However, if you need some of the build-only components, you would find those in the Builder repository.

If you are a .Net developer, you can find the Core Runtime & tools directly in AppStream as the “dotnet” package. When you build applications you will be pulling most of your dependencies from Microsoft or the upstream of those dependencies. As a .Net developer, you will not need the Builder repository.

Moving on to the traditionally compiled languages, the Builder repository is really targeted to you. For languages like C and C++, many of the header files, devel packages, etc. can be found in the Builder repository. As this sort of developer, you will definitely want to have the Builder repository enabled on your build machines. However, you should not, normally, need the repository enabled on your runtime deployments.

Much like .Net, the LLVM/Clang, Go & Rust language compilers are provided directly in AppStream with a few tools to support development. If you use one of these languages, you won’t need the Builder repository.

Last but not least, when you want to package and deploy your applications, you can find many of the tools that support you in this process in the Builder repository as well. For example, meson, dejagnu, and doxygen are available for use.

Hopefully, you found this description of the new Code Ready Linux Builder helpful and we really hope the changes to the content repositories with RHEL8 make things simpler and easier to find.

Источник

Red Hat CodeReady Containers

OpenShift on your laptop. CodeReady containers gets you up and running with an OpenShift cluster on your local machine in minutes.

Local development with OpenShift

CodeReady Containers is the quickest way to get started building OpenShift clusters. It is designed to run on a local computer to simplify setup and testing, and emulate the cloud development environment locally with all of the tools needed to develop container-based applications.

Whatever your programming language, CRC will host your application. CodeReady Containers brings a minimal, preconfigured OpenShift 4.1 (or newer) cluster to your local PC without the need for a server-based infrastructure.

With CodeReady Containers (CRC), you can create microservices, build them into images, and run them in Kubernetes-hosted containers, right on your laptop or desktop running Linux, macOS, or Windows 10.

CodeReady Containers is designed for local development and testing on an OpenShift 4 cluster. For running an OpenShift 3 cluster locally, see Red Hat Container Development Kit (CDK).

Features

New technology beyond the minishift experience.

Includes a local version of the OpenShift Container Platform (OCP).

Improved startup process and integrated service mesh, serverless, and connects to VS Code with the OpenShift Connector.

Automatically installs and enables the xpaas templates, anyuid access controls, and admin-user add-ons.

A single-node cluster with a number of templates and includes a local Docker registry and its API.

Источник

Разбираемся с развёртыванием CodeReady Containers на Linux

Подумываете ли вы о том, чтобы использовать Red Hat CodeReady Containers (CRC) для решения задач локальной OpenShift-разработки? Собираетесь ли устанавливать CRC на Linux? В этом материале я хочу рассказать именно об этом. Мы обсудим некоторые особенности работы CRC и поговорим о настройке контейнеров.

Тут используется система CRC версии 1.21.0, в основе которой лежит OpenShift Container Platform (OCP) версии 4.6.9. Я устанавливаю CRC на Debian 10 GNU/Linux, но нам подойдёт любой современный дистрибутив Linux — вроде Fedora или Ubuntu. CRC 1.21.0 можно установить на Linux-хосте, который удовлетворяет следующим требованиям:

• На нём установлены KVM и libvirt .
• Его сетевые настройки выполняются с использованием NetworkManager .
• Пользователь, устанавливающий CRC, имеет sudo-доступ к этому хосту.

Перед установкой CRC нужно будет загрузить tarball-дистрибутив CRC и так называемый «pull secret». «Pull secret» — это JSON-файл, который содержит аутентификационную информацию, необходимую для доступа к защищённым реестрам образов, поддерживаемым Red Hat. Если вы не являетесь клиентом Red Hat — вы можете присоединиться к Red Hat Developer Program, к программе Red Hat для разработчиков, и бесплатно загрузить этот файл. Участие в этой программе позволяет, кроме того, загрузить tarball-дистрибутив CRC. А отсюда дистрибутив можно скачать без лишних формальностей.

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

Обзор порядка развёртывания CodeReady Containers

Если описать работу CRC в общих чертах, то окажется, что эта система создаёт виртуальную машину, на которой работает OpenShift-кластер, состоящий из одного узла. Этот узел одновременно играет и роль главного узла (master node), и роль рабочего узла (worker node). Платформа OpenShift не устанавливается при развёртывании CRC. CRC запускает OpenShift из предустановленного образа виртуальной машины. Процесс развёртывания CRC показан на следующей схеме.

CRC, работая на Linux-хосте, использует libvirt для создания сети, пула хранения данных и виртуальной машины CRC. Данные этой виртуальной машины хранятся на постоянной основе в томе libvirt . Это обеспечивает то, что объекты, создаваемые пользователем в OpenShift, не будут исчезать после перезагрузок CRC.

У экземпляра OpenShift имеется фиксированный набор хранилищ PersistentVolume . Пользователи могут подключать эти хранилища к подам приложений, выполняя запросы PersistentVolumeClaim (PVC). Тут поддерживаются все режимы доступа к хранилищам: ReadWriteOnce , ReadWriteMany и ReadOnlyMany . Содержимое постоянных хранилищ информации размещается на хосте, в директории /var/mnt/pv-data .

А как насчёт интегрированного реестра образов? В основе реестра образов в OpenShift лежит хранилище PersistentVolume , работа с которым организована через общедоступный маршрут default-route-openshift-image-registry.apps-crc.testing . Пользователи могут применять этот маршрут для отправки образов своих контейнеров в реестр до запуска их в OpenShift.

Последнее, на что стоит обратить внимание, анализируя вышеприведённую схему, представлено конфигурацией DNS. Зачем это нужно? CRC настраивает разрешение DNS-имён на Linux-хосте таким образом, чтобы запросы к конечным точкам api.crc.testing и *.apps-crc.testing перенаправлялись бы к экземпляру OpenShift. Программа NetworkManager , нужная для работы CRC, используется для выполнения таких настроек DNS. CRC просит NetworkManager развернуть экземпляр dnsmasq , который перенаправляет DNS-запросы для конечных точек OpenShift другому экземпляру dnsmasq , развёрнутому внутри виртуальной машины. А разрешением имён занимается именно этот второй экземпляр dnsmasq .

Настройка CodeReady Containers

В этом разделе мы поговорим о некоторых конфигурационных параметрах CRC, которые вам может понадобиться подстроить под свои нужды. По умолчанию виртуальной машине CRC даётся 4 vCPU, 8790 МиБ RAM и 31 Гиб дискового пространства. Эти значения, что зависит от конкретной ситуации, может понадобиться увеличить. Я, на своём настольном компьютере, предпочитаю увеличивать количество vCPU до 10. Сделать это можно с помощью следующей команды:

Стандартный размер оперативной памяти в 8790 МиБ кажется мне достаточно скромным. Большая часть этой памяти используется компонентами OpenShift. В результате из 8790 МиБ памяти приложениям пользователя доступно лишь что-то наподобие 2 Гиб. На моём настольном компьютере достаточно много RAM. Обычно я повышаю размер памяти, доступной CRC, примерно до 46 ГиБ:

Если говорить о дисковом пространстве, то, как уже было сказано, по умолчанию виртуальной машине CRC выделяется 31 ГиБ. Примерно половина этой ёмкости нам не доступна, так как она используется операционной системой Red Hat CoreOS и компонентами OpenShift. Около 16 ГиБ остаётся на нужды интегрированного реестра образов и других хранилищ информации (PVC), создаваемых для приложений. И, хотя стандартный размер дискового пространства в 31 ГиБ — это вполне прилично, я предпочитаю увеличивать этот показатель до 120 ГиБ, делая это лишь для того чтобы привести его в соответствие со стандартным дисковым пространством кластеров OCP. Обратите внимание на то, что CRC позволяет увеличивать размер дискового пространства не только при первоначальной настройке системы, но и в любое время после её установки. Для настройки размеров дискового пространства, доступного CRC, можно воспользоваться такой командой:

CRC необходим файл «pull secret» OpenShift. Я обычно указываю CRC путь к соответствующему файлу, который храню в защищённом месте домашней директории. Этот файл необходим OpenShift вне зависимости от того, как именно была произведена установка OpenShift. Тот же «pull secret», который использован для CRC, может быть применён для установки OpenShift с использованием установщика OpenShift. После того, как я загрузил нужный файл с сайта Red Hat и сохранил его по адресу

/.mysecrets/ocp/pull-secret.json , мне нужно сообщить о его местоположении CRC:

И последний параметр, о котором мне хочется рассказать, это — consent-telemetry . Если заблаговременно его настроить, можно избежать вопроса Would you like to contribute anonymous usage statistics [y/N], который будет задавать CRC в процессе работы. Вот команда для настройки этого параметра:

CRC сохраняет вышеописанные настройки в файле

/.crc/crc.json . Если хотите — можете просто отредактировать этот файл. Полный список доступных конфигурационных параметров CRC можно узнать, выполнив следующую команду:

Теперь, когда мы уладили вопросы, касающиеся настройки CRC, ничто не мешает нам поговорить о подготовке Linux-хоста к запуску OpenShift-кластера.

Установка CodeReady Containers

В этом разделе мы поговорим о подготовке Linux-хоста к запуску виртуальной машины CRC. Обратите внимание на то, что эти настройки выполняются лишь один раз. Для того чтобы приступить к делу и начать процесс установки CRC, выполним следующую команду:

А пока всё устанавливается — поговорим о бинарном файле CRC. Обратили ли вы внимание на то, что этот файл довольно-таки велик? В частности, его размер для CRC 1.21.0 составляет примерно 2,6 ГиБ. Почему он такой большой? Для того чтобы ответить на этот вопрос — давайте исследуем его структуру, схематическое представление которой представлено ниже.

Структура бинарного файла CRC

Бинарник CRC состоит из четырёх частей. Первая часть — это исполняемый код CRC. Вторая — это утилита admin-helper-linux , которая используется для обновления файла /etc/hosts . Третья — это исполняемый код демона crc-driver-libvirt , который реализует специфические функции виртуализации libvirt и абстрагирует детали виртуализации от ядра CRC. Четвёртая часть — это так называемый «CRC-бандл» (на схеме это crc_libvirt_4.6.9.crcbundle ). Этот бандл содержит образ виртуальной машины и именно на его долю приходится большая часть размера бинарника CRC.

Теперь вернёмся к установке CRC. На начальной стадии работы команда ./crc setup извлекает все компоненты, прикреплённые к исполняемому коду CRC, и размещает их в директории

/.crc . Встроенный в бинарник CRC-бандл представлен архивом tar.xz , который тут же распаковывается в папку

/.crc/cache . В бандле содержатся следующие материалы:

• Файл crc-bundle-info.json несёт в себе метаданные бандла. CRC обращается к этому файлу в процессе развёртывания системы.
• Образ виртуальной машины crc.qcow2 содержит предустановленный узел OpenShift. Этот образ будет использован в качестве базы для образа диска виртуальной машины CRC.
• Временный ключ id_ecdsa_crc используется CRC для подключения к виртуальной машине по SSH на начальном этапе работы, сразу после её первого запуска. После подключения к виртуальной машине CRC генерирует новую уникальную пару SSH-ключей и добавляет их в файл машины

core/.ssh/authorized_keys . Временный SSH-ключ удаляется из этого файла, а значит — его больше нельзя будет использовать для подключения к соответствующей виртуальной машине.

В файле kubeadmin-password хранится пароль пользователя kubeadmin в OpenShift.

Файл kubeconfig позволяет входить в OpenShift в виде пользователя kube:admin . Этот файл включает в себя приватный ключ, необходимый для успешного прохождения процедуры аутентификации.

Исполняемый файл oc — это клиент oc , версия которого соответствует версии OpenShift-кластера, входящего в состав бандла.

После того, как процедура извлечения компонентов CRC завершится, директория

/.crc будет выглядеть так:

Следующий достойный внимания шаг, выполняемый в процессе установки CRC, представляет собой настройку DNS на Linux-хосте. CRC настраивает DNS так, чтобы запросы на подключение к конечным точкам api.crc.testing и *.apps-crc.testing перенаправлялись бы к экземпляру OpenShift. Заранее известно то, что данный экземпляр OpenShift собирается открыть свои конечные точки на жёстко заданном IP-адресе 192.168.130.11 . Как же CRC добивается правильного разрешения DNS-имён для конечных точек OpenShift? CRC создаёт для этого файл /etc/NetworkManager/conf.d/crc-nm-dnsmasq.conf , содержащий следующую настройку:

Эта настройка сообщает NetworkManager о том, что, во-первых, надо запустить экземпляр dnsmasq , а во-вторых — что надо модифицировать файл /etc/resolv.conf на компьютере так, чтобы этот экземпляр dnsmasq рассматривался бы как DNS-сервер, используемый по умолчанию. На следующем шаге CRC настраивает сервер dnsmasq , создавая конфигурационный файл /etc/NetworkManager/dnsmasq.d/crc.conf с таким содержимым:

Благодаря этому DNS-запросы для доменов crc.testing и apps-crc.testing , а так же — для всех их поддоменов, перенаправляются к DNS-серверу 192.168.130.11 . Этот DNS-сервер будет развёрнут внутри виртуальной машины CRC и будет отвечать за разрешение имён конечных точек OpenShift.

Обратите внимание на то, что вышеописанный перенаправляющий DNS-сервер создаётся только в том случае, если хост не использует для разрешения DNS-имён systemd-resolved . Если ваш хост использует systemd-resolved , это значит, что CRC настроит перенаправление с его помощью, не прибегая к запуску дополнительного перенаправляющего сервера dnsmasq .

На последнем этапе работы команды ./crc setup выполняется создание сети libvirt . Что для этого нужно? CRC создаёт libvirt-сеть с именем crc типа NAT. Единственный хост в этой сети получит IP-адрес 192.168.130.11 :

В этой сети будет находиться виртуальная машина CRC. Этой виртуальной машине будет назначен MAC-адрес 52:fd:fc:07:21:82 . Благодаря вышеприведённым настройкам этой машине назначается фиксированный IP-адрес 192.168.130.11 . Оба эти адреса жёстко заданы в CRC.

Создание libvirt-сети было последним шагом установки CRC, о котором я хотел рассказать. В следующем разделе мы займёмся созданием и запуском виртуальной машины CRC.

Запуск CodeReady Containers

После того, как завершится работа команды ./crc setup , выполним следующую команду, которая позволяет создать и запустить виртуальную машину CRC:

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

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

Далее CRC создаёт libvirt-пул хранения данных, называемый crc и располагающийся в директории

/.crc/machines/crc . В этом пуле создаётся образ диска для виртуальной машины crc.qcow2 размером 120 ГиБ. Мы выбрали именно этот размер, настроив параметр disk-size в одном из предыдущих разделов. Это — так называемый «thin-provisioned-образ». Он не сразу занимает всё выделенное ему пространство, его физический размер увеличивается по мере необходимости, при записи в него данных. CRC, кроме того, поддерживает изменение размера этого образа. Если пользователь решит изменить параметр disk-size — CRC изменит образ перед запуском виртуальной машины. Описание пула хранения данных libvirt может выглядеть так, как показано ниже:

После того, как образ диска для виртуальной машины готов, CRC создаёт саму виртуальную машину и запускает её. Эта виртуальная машина носит имя crc , посмотреть её описание можно так:

Количество vCPU и размер оперативной памяти виртуальной машины соответствуют ранее настроенным параметрам cpus и memory . Из кода описания виртуальной машины можно узнать о том, что машина базируется на образе

/.crc/machines/crc/crc.qcow2 . А этот образ, на самом деле, является лишь образом-наложением (overlay image), в основе которого лежит базовый образ

/.crc/cache/crc_libvirt_4.6.9/crc.qcow2 . В начале работы образ-наложение пуст. В него попадает то, что пишет на диск виртуальная машина CRC. Все изменения, внесённые в данные виртуальной машиной, на постоянной основе хранятся в образе-наложении, они не теряются после перезапуска машины. Это значит, что конфигурация OpenShift никуда не исчезнет в промежутке между выполнением команд ./crc stop и ./crc start .

Далее, CRC создаёт новую пару SSH-ключей, которая будет использоваться для подключения к виртуальной машине по SSH с учётной записью пользователя core . Публичный ключ из этой пары добавляется в файл

core/.ssh/authorized_keys виртуальной машины, что и позволяет пользователю core к ней подключаться. CRC использует SSH для выполнения дальнейших настроек виртуальной машины в процессе её запуска.

Если пользователь поменял параметр disk-size , это значит, что файловая система нуждается в расширении, выполняемом для того, чтобы она охватывала бы всё доступное дисковое пространство. Это достигается путём выполнения команды xfs_growfs / внутри виртуальной машины. Как уже было сказано, по умолчанию в CRC в качестве размера диска установлен 31 ГиБ. В этот момент файловая система расширяется до 120 ГиБ, до того размера, который мы задали в ходе настройки CRC.

Теперь CRC запускает внутри виртуальной машины DNS-сервер — podman-контейнер, в котором работает dnsmasq . Этот DNS-сервер разрешает доменные имена *.apps-crc.testing , api.crc.testing и api-int.crc.testing в IP-адрес 192.168.130.11 , который является адресом самой виртуальной машины. Эти доменные имена назначены широко известным конечным точкам OpenShift, то есть, соответственно — входному маршрутизатору, серверу API и точке доступа к внутреннему API. Этот DNS-сервер используется и виртуальной машиной, и Linux-хостом. Запросы хоста доходят до этого сервера благодаря перенаправляющему DNS-серверу, о котором мы говорили выше.

В процессе запуска виртуальной машины CRC добавляет в /etc/hosts Linux-хоста следующую строчку:

Я не знаю точно — для чего это делается. Разрешение вышеупомянутых имён уже выполняется dnsmasq-сервером, который работает внутри виртуальной машины CRC. Но полагаю, что, в любом случае, полезно знать о том, что CRC пишет эти данные в /etc/hosts .

На следующем шаге запуска виртуальной машины CRC запускает службу kubelet , которая, в свою очередь, запускает службы OpenShift. Если сертификат клиента kubelet истёк в то время, пока виртуальная машина CRC была выключена, kubelet выполнит запрос на подпись сертификата (Certificate Signing Request, CSR) для получения нового сертификата. CRC выполняет проверку на наличие новых CSR и автоматически их одобряет.

На последнем шаге запуска CRC добавляет файл «pull secret» пользователя в кластер OpenShift.

Конфигурационные данные, имеющие отношение к конкретному экземпляру виртуальной машины CRC, хранятся в директории .crc/machines/crc . Взглянуть на них можно так:

Если сейчас вам удалось запустить собственную виртуальную машину CRC — примите поздравления!

Полезные команды CodeReady Containers

В этом разделе мне хотелось бы рассказать о нескольких командах, которые пригодятся тем, кто пользуется CRC.

Для того чтобы открыть в браузере, используемом по умолчанию, OpenShift Web Console — воспользуйтесь такой командой:

Так можно вывести сведения об учётных данных пользователя OpenShift:

К виртуальной машине CRC можно подключиться по SSH в виде пользователя core :

У этого пользователя есть полные административные привилегии, доступные через команду sudo .

Итоги

В этом материале раскрыты вопросы развёртывания CodeReady Containers на Linux-хосте. Мы начали с рассмотрения требований к системе, на которой планируется запускать CRC. В разделе, посвящённом обзору установки CRC, мы поговорили о том, как CRC взаимодействует с libvirt для обеспечения работы виртуальной машины OpenShift. Мы, кроме того, обсудили особенности настроек DNS, выполняемых CRC. Перед тем, как переходить к запуску системы, мы рассмотрели особенности настройки CRC и предоставили в распоряжение виртуальной машины дополнительные ресурсы в размерах, превышающих те, которые используются по умолчанию. Мы подробно разобрали установку и запуск CRC. И, наконец, я рассказал о нескольких командах, которые кажутся мне полезными.

Вот моё видео, посвящённое развёртыванию CRC на Linux.

Надеюсь, вам было интересно читать мой рассказ о CodeReady Containers.

Пользуетесь ли вы Red Hat CodeReady Containers?

Источник