OpenShift - Guía rápida

OpenShift es una plataforma de desarrollo en la nube como servicio (PaaS) alojada por Red Hat. Es una plataforma fácil de usar basada en la nube de código abierto que se utiliza para crear, probar y ejecutar aplicaciones, y finalmente implementarlas en la nube.

OpenShift es capaz de administrar aplicaciones escritas en diferentes lenguajes, como Node.js, Ruby, Python, Perl y Java. Una de las características clave de OpenShift es que es extensible, lo que ayuda a los usuarios a admitir la aplicación escrita en otros idiomas.

OpenShift viene con varios conceptos de virtualización como su capa de abstracción. El concepto subyacente de OpenShift se basa en la virtualización.

Virtualización

En general, la virtualización se puede definir como la creación de un sistema virtual en lugar de una versión física o real de cualquier cosa a partir del sistema, el almacenamiento o un sistema operativo. El objetivo principal de la virtualización es hacer que la infraestructura de TI sea más escalable y confiable. El concepto de virtualización ha existido desde hace décadas y con la evolución de la industria de TI en la actualidad, se puede aplicar a una amplia gama de capas, desde el nivel del sistema, el nivel del hardware hasta la virtualización del nivel del servidor.

Cómo funciona

Puede describirse como una tecnología en la que cualquier aplicación o sistema operativo se abstrae de su capa física real. Un uso clave de la tecnología de virtualización es la virtualización de servidores, que utiliza un software llamado hipervisor para abstraer la capa del hardware subyacente. El rendimiento de un sistema operativo que se ejecuta en virtualización es tan bueno como cuando se ejecuta en el hardware físico. Sin embargo, el concepto de virtualización es popular ya que la mayoría de los sistemas y aplicaciones que se ejecutan no requieren el uso del hardware subyacente.

Arquitectura física vs virtual

Tipos de virtualización

• Application Virtualization- En este método, la aplicación se extrae del sistema operativo subyacente. Este método es muy útil en el que la aplicación se puede ejecutar de forma aislada sin depender del sistema operativo subyacente.

• Desktop Virtualization- Este método se utiliza para reducir la carga de la estación de trabajo en la que se puede acceder al escritorio de forma remota, utilizando un cliente ligero en el escritorio. En este método, los escritorios se ejecutan principalmente en un centro de datos. Un ejemplo clásico puede ser una imagen de escritorio virtual (VDI) que se utiliza en la mayoría de las organizaciones.

• Data Virtualization - Es un método de abstracción y alejamiento del método tradicional de gestión de datos y datos.

• Server Virtualization- En este método, los recursos relacionados con el servidor se virtualizan, lo que incluye el servidor físico, el proceso y el sistema operativo. El software que permite esta abstracción a menudo se denomina hipervisor.

• Storage Virtualization - Es el proceso de agrupar varios dispositivos de almacenamiento en un solo dispositivo de almacenamiento que se administra desde una única consola central.

• Network Virtualization - Es el método en el que todos los recursos de red disponibles se combinan dividiendo el ancho de banda y los canales disponibles, cada uno de los cuales es independiente entre sí.

OpenShift

OpenShift es una plataforma de aplicaciones como servicio (PaaS) habilitada para la nube. Es una tecnología de código abierto que ayuda a las organizaciones a trasladar su infraestructura y plataforma de aplicaciones tradicionales de medios físicos y virtuales a la nube.

OpenShift admite una gran variedad de aplicaciones, que se pueden desarrollar e implementar fácilmente en la plataforma en la nube de OpenShift. OpenShift básicamente admite tres tipos de plataformas para desarrolladores y usuarios.

Infraestructura como servicio (IaaS)

En este formato, el proveedor de servicios proporciona máquinas virtuales a nivel de hardware con alguna configuración de hardware virtual predefinida. Hay varios competidores en este espacio, desde la nube de AWS Google, Rackspace y muchos más.

El principal inconveniente de tener IaaS después de un largo procedimiento de configuración e inversión es que uno sigue siendo responsable de instalar y mantener el sistema operativo y los paquetes del servidor, administrar la red de infraestructura y encargarse de la administración básica del sistema.

Software como servicio (SaaS)

Con SaaS, uno tiene la menor preocupación por la infraestructura subyacente. Es tan simple como plug and play, en el que el usuario solo tiene que registrarse en los servicios y comenzar a usarlos. El principal inconveniente de esta configuración es que solo se puede realizar una cantidad mínima de personalización, que está permitida por el proveedor de servicios. Uno de los ejemplos más comunes de SaaS es Gmail, donde el usuario solo necesita iniciar sesión y comenzar a usarlo. El usuario también puede realizar algunas modificaciones menores en su cuenta. Sin embargo, no es muy útil desde el punto de vista del desarrollador.

Plataforma como servicio (PaaS)

Puede considerarse como una capa intermedia entre SaaS e IaaS. El objetivo principal de la evaluación de PaaS es para los desarrolladores en los que el entorno de desarrollo se puede activar con unos pocos comandos. Estos entornos están diseñados de tal manera que pueden satisfacer todas las necesidades de desarrollo, desde tener un servidor de aplicaciones web con una base de datos. Para hacer esto, solo necesita un comando y el proveedor de servicios hace todo por usted.

¿Por qué utilizar OpenShift?

OpenShift proporciona una plataforma común para que las unidades empresariales alojen sus aplicaciones en la nube sin preocuparse por el sistema operativo subyacente. Esto hace que sea muy fácil de usar, desarrollar e implementar aplicaciones en la nube. Una de las características clave es que proporciona recursos de red y hardware administrados para todo tipo de desarrollo y pruebas. Con OpenShift, el desarrollador de PaaS tiene la libertad de diseñar su entorno requerido con especificaciones.

OpenShift ofrece diferentes tipos de acuerdos de nivel de servicio cuando se trata de planes de servicio.

Free - Este plan está limitado a tres años con 1GB de espacio para cada uno.

Bronze - Este plan incluye 3 años y se expande hasta 16 años con 1GB de espacio por año.

Sliver - Este es un plan de bronce de 16 años, sin embargo, tiene una capacidad de almacenamiento de 6GB sin costo adicional.

Además de las características anteriores, OpenShift también ofrece una versión local conocida como OpenShift Enterprise. En OpenShift, los desarrolladores tienen la ventaja de diseñar aplicaciones escalables y no escalables y estos diseños se implementan utilizando servidores HAproxy.

Caracteristicas

Hay varias funciones compatibles con OpenShift. Pocos de ellos son ...

• Soporte de múltiples idiomas
• Soporte de múltiples bases de datos
• Sistema de cartucho extensible
• Gestión de versiones de código fuente
• Implementación con un clic
• Soporte para múltiples entornos
• Flujo de trabajo de desarrolladores estandarizados
• Gestión de dependencias y edificios
• Escalado automático de aplicaciones
• Consola web receptiva
• Conjunto de herramientas de línea de comandos enriquecido
• Inicio de sesión SSH remoto en aplicaciones
• Soporte de API de descanso
• Pila de aplicaciones de autoservicio bajo demanda
• Servicios de base de datos integrados
• Gestión continua de integración y versiones
• Integración IDE
• Depuración remota de aplicaciones

OpenShift nació a partir de su base denominada OpenShift V2, que se basó principalmente en el concepto de año y cartuchos, donde cada componente tiene sus especificaciones desde la creación de la máquina hasta la implementación de la aplicación, desde la construcción hasta la implementación de la aplicación.

Cartridges - Fueron el punto focal de la construcción de una nueva aplicación a partir del tipo de aplicación que el entorno requiere para ejecutarlas y todas las dependencias satisfechas en esta sección.

year- Se puede definir como la máquina o servidor bear metal con ciertas especificaciones en cuanto a recursos, memoria y CPU. Fueron considerados como una unidad fundamental para ejecutar una aplicación.

Application - Estos simplemente se refieren a la aplicación o cualquier aplicación de integración que se implementará y ejecutará en el entorno OpenShift.

A medida que profundicemos en la sección, analizaremos los diferentes formatos y ofertas de OpenShift. En los primeros días, OpenShift tenía tres versiones principales.

OpenShift Origin- Esta fue la adición de la comunidad o la versión de código abierto de OpenShift. También se conoció como proyecto upstream para otras dos versiones.

OpenShift Online - Es una PaaS pública como servicio alojado en AWS.

OpenShift Enterprise - es la versión reforzada de OpenShift con licencias de proveedores e ISV.

OpenShift en línea

OpenShift online es una oferta de la comunidad OpenShift mediante la cual se pueden crear, implementar y escalar rápidamente aplicaciones en contenedores en la nube pública. Es la plataforma de alojamiento y desarrollo de aplicaciones de nube pública de Red Hat, que permite el aprovisionamiento, la gestión y el escalado automatizados de la aplicación, lo que ayuda al desarrollador a centrarse en escribir la lógica de la aplicación.

Configuración de una cuenta en Red Hat OpenShift Online

Step 1 - Vaya al navegador y visite el sitio https://manage.openshift.com/

Step 2 - Si tiene una cuenta de Red Hat, inicie sesión en la cuenta de OpenShift utilizando el ID de inicio de sesión y la contraseña de Red Hat utilizando la siguiente URL. https://developers.redhat.com

Step 3 - Si no tiene una cuenta de Red Hat para iniciar sesión, regístrese en el servicio en línea de OpenShift usando el siguiente enlace.

https://developers.redhat.com/auth/realms/rhd/login-actions/registration?code=G4w-myLd3GCH_QZCqMUmIOQlU7DIf_gfIvGu38nnzZQ.cb229a9d-3cff-4c58-b7f6-7b2c9eb17926

Después de iniciar sesión, verá la siguiente página.

Una vez que tenga todas las cosas en su lugar, Red Hat mostrará algunos detalles básicos de la cuenta como se muestra en la siguiente captura de pantalla.

Finalmente, cuando inicie sesión, verá la siguiente página.

Plataforma de contenedores OpenShift

La plataforma de contenedores OpenShift es una plataforma empresarial que ayuda a múltiples equipos, como el de desarrollo y operaciones de TI, a construir e implementar infraestructura en contenedores. Todos los contenedores integrados en OpenShift utilizan una tecnología de contenedorización de Docker muy confiable, que se puede implementar en cualquier centro de datos de plataformas en la nube alojadas públicamente.

La plataforma de contenedores OpenShift se conocía formalmente como OpenShift Enterprises. Es una plataforma privada local como servicio de Red Hat, construida sobre el concepto central de contenedores de aplicaciones con tecnología de Docker, donde la orquestación y la administración son administradas por Kubernetes.

En otras palabras, OpenShift une a Docker y Kubernetes al nivel empresarial. Es un software de plataforma de contenedores para que las unidades empresariales implementen y administren a los solicitantes en una infraestructura de su propia elección. Por ejemplo, hospedar instancias de OpenShift en instancias de AWS.

La plataforma de contenedores OpenShift está disponible en two package levels.

OpenShift Container Local- Esto es para aquellos desarrolladores que deseen implementar y probar aplicaciones en la máquina local. Este paquete lo utilizan principalmente los equipos de desarrollo para desarrollar y probar aplicaciones.

OpenShift Container Lab - Esto está diseñado para una evaluación extendida de la aplicación desde el desarrollo hasta la implementación en el entorno previo a la producción.

OpenShift dedicado

Esta es otra oferta añadida a la cartera de OpenShift, en la que existe la opción del cliente de alojar una plataforma en contenedores en cualquiera de las nubes públicas de su elección. Esto le da al usuario final una verdadera sensación de oferta de múltiples nubes, donde pueden usar OpenShift en cualquier nube que satisfaga sus necesidades.

Esta es una de las ofertas más recientes de Red Hat, en la que el usuario final puede usar OpenShift para crear una implementación de prueba y ejecutar su aplicación en OpenShift, que está alojada en la nube.

Características de OpenShift Dedicated

OpenShift dedicado ofrece una plataforma de aplicación de solución personalizada en la nube pública y se hereda de la tecnología OpenShift 3.

• Extensible and Open - Esto se basa en el concepto abierto de Docker y se implementa en la nube, por lo que se puede gastar cuando sea necesario.

• Portability - Como está construido con Docker, las aplicaciones que se ejecutan en Docker se pueden enviar fácilmente de un lugar a otro, donde Docker es compatible.

• Orchestration - Con OpenShift 3, una de las características clave de la orquestación de contenedores y la administración de clústeres es compatible con Kubernetes, que se ofreció con OpenShift versión 3.

• Automation - Esta versión de OpenShift está habilitada con la función de administración de código fuente, automatización de compilación y automatización de implementación, lo que la hace muy popular en el mercado como proveedor de plataforma como servicio.

Competidores de OpenShift

Google App Engine- Esta es la plataforma gratuita de Google para desarrollar y alojar aplicaciones web. El motor de aplicaciones de Google ofrece una plataforma de implementación y desarrollo rápido.

Microsoft Azure - La nube de Azure está alojada por Microsoft en sus centros de datos.

Amazon Elastic Cloud Compute - Son servicios integrados proporcionados por Amazon, que ayudan a desarrollar y alojar aplicaciones web escalables en la nube.

Cloud Foundry - es una plataforma PaaS de código abierto para aplicaciones Java, Ruby, Python y Node.js.

CloudStack - CloudStack de Apache es un proyecto desarrollado por Citrix y está diseñado para convertirse en un competidor directo de OpenShift y OpenStack.

OpenStack - Otra tecnología en la nube proporcionada por Red Hat para la computación en la nube.

Kubernetes - Es una tecnología de administración de clústeres y orquestación directa creada para administrar el contenedor Docker.

OpenShift es un sistema en capas en el que cada capa está estrechamente vinculada con la otra capa mediante Kubernetes y el clúster de Docker. La arquitectura de OpenShift está diseñada de tal manera que puede admitir y administrar contenedores Docker, que se alojan encima de todas las capas que utilizan Kubernetes. A diferencia de la versión anterior de OpenShift V2, la nueva versión de OpenShift V3 admite la infraestructura en contenedores. En este modelo, Docker ayuda en la creación de contenedores livianos basados ​​en Linux y Kubernetes admite la tarea de orquestar y administrar contenedores en múltiples hosts.

Componentes de OpenShift

Uno de los componentes clave de la arquitectura OpenShift es administrar la infraestructura en contenedores en Kubernetes. Kubernetes es responsable de la implementación y la gestión de la infraestructura. En cualquier clúster de Kubernetes, podemos tener más de un maestro y varios nodos, lo que garantiza que no haya ningún punto de falla en la configuración.

Componentes de la máquina maestra de Kubernetes

Etcd- Almacena la información de configuración, que puede ser utilizada por cada uno de los nodos del cluster. Es un almacén de valor clave de alta disponibilidad que se puede distribuir entre varios nodos. Solo debe ser accesible desde el servidor de API de Kubernetes, ya que puede contener información confidencial. Es una tienda de valor clave distribuida accesible para todos.

API Server- Kubernetes es un servidor API que proporciona todas las operaciones en el clúster utilizando la API. El servidor API implementa una interfaz que significa que diferentes herramientas y bibliotecas pueden comunicarse fácilmente con él. Un kubeconfig es un paquete junto con las herramientas del lado del servidor que se pueden utilizar para la comunicación. Expone la API de Kubernetes ”.

Controller Manager- Este componente es responsable de la mayoría de los recolectores que regulan el estado del clúster y realizan una tarea. Puede considerarse como un demonio que se ejecuta en un bucle sin terminación y es responsable de recopilar y enviar información al servidor API. Trabaja para obtener el estado compartido del clúster y luego realizar cambios para llevar el estado actual del servidor al estado deseado. Los controladores clave son controlador de replicación, controlador de punto final, controlador de espacio de nombres y controlador de cuenta de servicio. El administrador del controlador ejecuta diferentes tipos de controladores para manejar nodos, puntos finales, etc.

Scheduler- Es un componente clave del maestro de Kubernetes. Es un servicio en master que se encarga de distribuir la carga de trabajo. Es responsable de rastrear la utilización de la carga de trabajo en los nodos del clúster y luego colocar la carga de trabajo en qué recursos están disponibles y aceptar la carga de trabajo. En otras palabras, este es el mecanismo responsable de asignar pods a los nodos disponibles. El programador es responsable de la utilización de la carga de trabajo y de la asignación de un pod a un nuevo nodo.

Componentes del nodo de Kubernetes

A continuación se muestran los componentes clave del servidor Node, que son necesarios para comunicarse con el maestro de Kubernetes.

Docker - El primer requisito de cada nodo es Docker, que ayuda a ejecutar los contenedores de aplicaciones encapsulados en un entorno operativo relativamente aislado pero ligero.

Kubelet Service- Este es un pequeño servicio en cada nodo, que es responsable de transmitir información desde y hacia el servicio del plano de control. Interactúa con etcd store para leer los detalles de configuración y los valores de Wright. Este se comunica con el componente maestro para recibir comandos y trabajar. El proceso de kubelet asume la responsabilidad de mantener el estado de trabajo y el servidor de nodo. Gestiona reglas de red, reenvío de puertos, etc.

Kubernetes Proxy Service- Este es un servicio proxy que se ejecuta en cada nodo y ayuda a que los servicios estén disponibles para el host externo. Ayuda a reenviar la solicitud a los contenedores correctos. El servicio proxy de Kubernetes es capaz de realizar un balanceo de carga primitivo. Se asegura de que el entorno de red sea predecible y accesible pero, al mismo tiempo, también esté aislado. Gestiona pods en nodos, volúmenes, secretos, creación de nuevos contenedores, chequeo de salud, etc.

Registro de contenedores OpenShift integrado

El registro de contenedores de OpenShift es una unidad de almacenamiento incorporada de Red Hat, que se utiliza para almacenar imágenes de Docker. Con la última versión integrada de OpenShift, ha creado una interfaz de usuario para ver imágenes en el almacenamiento interno de OpenShift. Estos registros son capaces de contener imágenes con etiquetas específicas, que luego se utilizan para crear contenedores a partir de ellas.

Términos de uso frecuente

Image- Las imágenes de Kubernetes (Docker) son los bloques de construcción clave de la infraestructura en contenedores. A partir de ahora, Kubernetes solo admite imágenes de Docker. Cada contenedor de un pod tiene su imagen de Docker ejecutándose en su interior. Al configurar un pod, la propiedad de la imagen en el archivo de configuración tiene la misma sintaxis que el comando Docker.

Project - Pueden definirse como la versión renombrada del dominio que estaba presente en la versión anterior de OpenShift V2.

Container - Son los que se crean después de que la imagen se implementa en un nodo de clúster de Kubernetes.

Node- Un nodo es una máquina en funcionamiento en el clúster de Kubernetes, que también se conoce como minion para master. Son unidades de trabajo que pueden ser una instancia física, VM o en la nube.

Pod- Un pod es una colección de contenedores y su almacenamiento dentro de un nodo de un clúster de Kubernetes. Es posible crear una vaina con varios contenedores en su interior. Por ejemplo, mantener el contenedor de la base de datos y el contenedor del servidor web dentro del pod.

En este capítulo, aprenderemos sobre la configuración del entorno de OpenShift.

Requisitos del sistema

Para configurar OpenShift empresarial, es necesario tener una cuenta de Red Hat activa. Como OpenShift funciona en la arquitectura maestra y de nodo de Kubernetes, debemos configurar ambos en máquinas separadas, en las que una máquina actúa como maestra y la otra funciona en el nodo. Para configurar ambos, existen requisitos mínimos del sistema.

Configuración de la máquina maestra

Los siguientes son los requisitos mínimos del sistema para la configuración de la máquina maestra.

• Una máquina base alojada en un entorno físico, virtual o en cualquier entorno de nube.

• Al menos Linux 7 con los paquetes necesarios en esa instancia.

• 2 núcleos de CPU.

• Al menos 8 GB de RAM.

• 30 GB de memoria interna en disco duro.

Configuración de la máquina de nodo

• Imagen de base física o virtual como se proporciona para la máquina maestra.
• Al menos Linux 7 en la máquina.
• Docker instalado con una versión no inferior a 1.6.
• 1 núcleo de CPU.
• 8 GB de RAM.
• Disco duro de 15 GB para alojar imágenes y 15 GB para almacenar imágenes.

Guía paso a paso para la configuración de OpenShift

En la siguiente descripción, configuraremos el entorno de laboratorio OpenShift, que luego se puede extender a un clúster más grande. Como OpenShift requiere una configuración maestra y de nodo, necesitaríamos al menos dos máquinas alojadas en máquinas virtuales, físicas o en la nube.

Step 1- Primero instale Linux en ambas máquinas, donde Linux 7 debería ser la versión mínima. Esto se puede hacer usando los siguientes comandos si uno tiene una suscripción activa a Red Hat.

# subscription-manager repos --disable = "*"

# subscription-manager repos --enable = "rhel-7-server-rpms"

# subscription-manager repos --enable = "rhel-7-server-extras-rpms"

# subscription-manager repos --enable = "rhel-7-server-optional-rpms"

# subscription-manager repos --enable = "rhel-7-server-ose-3.0-rpms"

# yum install wget git net-tools bind-utils iptables-services bridge-utils

# yum install wget git net-tools bind-utils iptables-services bridge-utils

# yum install python-virtualenv

# yum install gcc

# yum install httpd-tools

# yum install docker

# yum update

Una vez que tengamos todos los paquetes base anteriores instalados en ambas máquinas, el siguiente paso sería configurar Docker en las respectivas máquinas.

Step 2- Configure Docker para que permita la comunicación insegura solo en la red local. Para esto, edite el archivo Docker dentro de / etc / sysconfig. Si el archivo no está presente, debe crearlo manualmente.

# vi /etc/sysconfig/docker
OPTIONS = --selinux-enabled --insecure-registry 192.168.122.0/24

Después de configurar Docker en la máquina maestra, necesitamos configurar una comunicación sin contraseña entre ambas máquinas. Para ello, usaremos autenticación de clave pública y privada.

Step 3 - Genere claves en la máquina maestra y luego copie la clave id_rsa.pub en el archivo de claves autorizadas de la máquina nodo, lo cual se puede hacer usando el siguiente comando.

# ssh-keygen

# ssh-copy-id -i .ssh/id_rsa.pub [email protected]

Una vez que tenga toda la configuración anterior en su lugar, lo siguiente es configurar OpenShift versión 3 en la máquina maestra.

Step 4 - Desde la máquina maestra, ejecute el siguiente comando curl.

# sh <(curl -s https://install.openshift.com/ose)

El comando anterior pondrá la configuración en su lugar para OSV3. El siguiente paso sería configurar OpenShift V3 en la máquina.

Si no puede descargar de Internet directamente, entonces puede descargarlo de https://install.openshift.com/portable/oo-install-ose.tgz como un paquete tar desde el que el instalador puede ejecutar en la máquina maestra local.

Una vez que tengamos la configuración lista, debemos comenzar con la configuración real de OSV3 en las máquinas. Esta configuración es muy específica para probar el entorno para la producción real, tenemos LDAP y otras cosas en su lugar.

Step 5 - En la máquina maestra, configure el siguiente código ubicado en /etc/openshift/master/master-config.yaml

# vi /etc/openshift/master/master-config.yaml
identityProviders:
- name: my_htpasswd_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
file: /root/users.htpasswd
routingConfig:
subdomain: testing.com

A continuación, cree un usuario estándar para la administración predeterminada.

# htpasswd -c /root/users.htpasswd admin

Step 6- Como OpenShift usa el registro de Docker para configurar imágenes, necesitamos configurar el registro de Docker. Se utiliza para crear y almacenar las imágenes de Docker después de la compilación.

Cree un directorio en la máquina del nodo OpenShift usando el siguiente comando.

# mkdir /images

A continuación, inicie sesión en la máquina maestra con las credenciales de administrador predeterminadas, que se crean al configurar el registro.

# oc login
Username: system:admin

Cambie al proyecto creado por defecto.

# oc project default

Step 7 - Cree un registro de Docker.

#echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"registry"}}' | oc create -f -

Edite los privilegios del usuario.

#oc edit scc privileged
users:
- system:serviceaccount:openshift-infra:build-controller
- system:serviceaccount:default:registry

Crea y edita el registro de imágenes.

#oadm registry --service-account = registry --
config = /etc/openshift/master/admin.kubeconfig --
credentials = /etc/openshift/master/openshift-registry.kubeconfig --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}' --
mount-host = /images

Step 8 - Cree una ruta predeterminada.

De forma predeterminada, OpenShift usa OpenVswitch como red de software. Utilice el siguiente comando para crear una ruta predeterminada. Se utiliza para el equilibrio de carga y el enrutamiento de proxy. El enrutador es similar al registro de Docker y también se ejecuta en un registro.

# echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"router"}}' | oc create -f -

A continuación, edite los privilegios del usuario.

#oc edit scc privileged
users:
   - system:serviceaccount:openshift-infra:build-controller
   - system:serviceaccount:default:registry
   - system:serviceaccount:default:router

#oadm router router-1 --replicas = 1 --
credentials = '/etc/openshift/master/openshift-router.kubeconfig' --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}'

Step 9 - Configurar el DNS.

Para manejar la solicitud de URL, OpenShift necesita un entorno DNS que funcione. Esta configuración de DNS es necesaria para crear un comodín, que se requiere para crear un comodín de DNS que apunte a un enrutador.

# yum install bind-utils bind

# systemctl start named

# systemctl enable named

vi /etc/named.conf
options {listen-on port 53 { 10.123.55.111; };
forwarders {
   10.38.55.13;
   ;
};

zone "lab.com" IN {
   type master;
   file "/var/named/dynamic/test.com.zone";
   allow-update { none; };
};

Step 10- El paso final sería configurar el servidor github en la máquina maestra OpenShift V3, que es opcional. Esto se puede hacer fácilmente usando la siguiente secuencia de comandos.

#yum install curl openssh-server

#systemctl enable sshd

# systemctl start sshd

# firewall-cmd --permanent --add-service = http

# systemctl reload firewalld

#curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-

#yum install gitlab-ce

# gitlab-ctl reconfigure

Una vez que se completa la configuración anterior, puede verificar mediante la prueba e implementar aplicaciones, de las que sabremos más en los capítulos siguientes.

Antes de comenzar con la configuración e implementación reales de las aplicaciones, debemos comprender algunos términos y conceptos básicos que se utilizan en OpenShift V3.

Contenedores e imágenes

Imagenes

Estos son los bloques de construcción básicos de OpenShift, que se forman a partir de imágenes de Docker. En cada pod de OpenShift, el clúster tiene sus propias imágenes ejecutándose en su interior. Cuando configuramos un pod, tenemos un campo que se agrupará desde el registro. Este archivo de configuración extraerá la imagen y la implementará en el nodo del clúster.

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> Name of Pod
      spec:
containers:
- name: neo4j-server ------------------------> Name of the image
image: <Name of the Docker image>----------> Image to be pulled
imagePullPolicy: Always ------------->Image pull policy
command: [“echo”, “SUCCESS”] -------------------> Massage after image pull

Para extraer y crear una imagen a partir de él, ejecute el siguiente comando. OC es el cliente para comunicarse con el entorno OpenShift después de iniciar sesión.

$ oc create –f Tesing_for_Image_pull

Envase

Esto se crea cuando la imagen de Docker se implementa en el clúster de OpenShift. Al definir cualquier configuración, definimos la sección del contenedor en el archivo de configuración. Un contenedor puede tener varias imágenes ejecutándose dentro y todos los contenedores que se ejecutan en el nodo del clúster son administrados por OpenShift Kubernetes.

spec:
   containers:
   - name: py ------------------------> Name of the container
   image: python----------> Image going to get deployed on container
   command: [“python”, “SUCCESS”]
   restartPocliy: Never --------> Restart policy of container

A continuación se muestran las especificaciones para definir un contenedor que tiene varias imágenes ejecutándose en su interior.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
   image: tomcat: 8.0
   ports:
   - containerPort: 7500
      imagePullPolicy: Always
      -name: Database
      Image: mongoDB
      Ports:
      - containerPort: 7501
imagePullPolicy: Always

En la configuración anterior, hemos definido un pod de contenedores múltiples con dos imágenes de Tomcat y MongoDB en su interior.

Pods y servicios

Vainas

Pod se puede definir como una colección de contenedores y su almacenamiento dentro de un nodo del clúster de OpenShift (Kubernetes). En general, tenemos dos tipos de cápsulas, que van desde una cápsula de un solo contenedor hasta una cápsula de varios contenedores.

Single Container Pod - Estos se pueden crear fácilmente con el comando OC o mediante un archivo yml de configuración básica.

$ oc run <name of pod> --image = <name of the image from registry>

Créelo con un archivo yaml simple de la siguiente manera.

apiVersion: v1
kind: Pod
metadata:
   name: apache
spec:
   containers:
   - name: apache
   image: apache: 8.0
   ports:
      - containerPort: 7500
imagePullPolicy: Always

Una vez que se crea el archivo anterior, generará un pod con el siguiente comando.

$ oc create –f apache.yml

Multi-Container Pod- Las vainas de contenedores múltiples son aquellas en las que tenemos más de un contenedor corriendo en su interior. Se crean utilizando archivos yaml de la siguiente manera.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
   image: tomcat: 8.0
   ports:
      - containerPort: 7500
imagePullPolicy: Always
   -name: Database
   Image: mongoDB
   Ports:
      - containerPort: 7501
imagePullPolicy: Always

Después de crear estos archivos, simplemente podemos usar el mismo método anterior para crear un contenedor.

Service- Como tenemos un conjunto de contenedores que se ejecutan dentro de un pod, de la misma forma tenemos un servicio que se puede definir como un conjunto lógico de pods. Es una capa abstracta en la parte superior del pod, que proporciona una única IP y un nombre DNS a través del cual se puede acceder a los pods. El servicio ayuda a administrar la configuración del equilibrio de carga y a escalar el pod con mucha facilidad. En OpenShift, un servicio es un objeto REST cuya deificación se puede publicar en apiService en OpenShift master para crear una nueva instancia.

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
      - port: 8080
         targetPort: 31999

Construye y transmite

Construye

En OpenShift, la compilación es un proceso de transformación de imágenes en contenedores. Es el procesamiento el que convierte el código fuente en una imagen. Este proceso de construcción funciona en una estrategia predefinida de construcción de código fuente a imagen.

La construcción procesa múltiples estrategias y fuentes.

Desarrollar estrategias

• Source to Image- Se trata básicamente de una herramienta que ayuda a crear imágenes reproducibles. Estas imágenes siempre están listas para ejecutarse con el comando de ejecución de Docker.

• Docker Build - Este es el proceso en el que las imágenes se crean utilizando un archivo Docker ejecutando un comando de compilación de Docker simple.

• Custom Build - Estas son las compilaciones que se utilizan para crear imágenes base de Docker.

Construir fuentes

Git- Esta fuente se usa cuando el repositorio de git se usa para construir imágenes. El Dockerfile es opcional. Las configuraciones del código fuente tienen el siguiente aspecto.

source:
type: "Git"
git:
   uri: "https://github.com/vipin/testing.git"
   ref: "master"
contextDir: "app/dir"
dockerfile: "FROM openshift/ruby-22-centos7\nUSER example"

Dockerfile - El Dockerfile se utiliza como entrada en el archivo de configuración.

source:
   type: "Dockerfile"
   dockerfile: "FROM ubuntu: latest
   RUN yum install -y httpd"

Image Streams- Los flujos de imágenes se crean después de extraer las imágenes. La ventaja de un flujo de imágenes es que busca actualizaciones en la nueva versión de una imagen. Se utiliza para comparar cualquier número de imágenes de contenedor con formato de Docker identificadas por etiquetas.

Los flujos de imágenes pueden realizar una acción automáticamente cuando se crea una nueva imagen. Todas las compilaciones e implementaciones pueden observar la acción de la imagen y realizar una acción en consecuencia. A continuación se muestra cómo definimos construir una secuencia.

apiVersion: v1
kind: ImageStream
metadata:
   annotations:
      openshift.io/generated-by: OpenShiftNewApp
   generation: 1
   labels:
      app: ruby-sample-build
   selflink: /oapi/v1/namespaces/test/imagestreams/origin-ruby-sample
   uid: ee2b9405-c68c-11e5-8a99-525400f25e34
spec: {}
status:
   dockerImageRepository: 172.30.56.218:5000/test/origin-ruby-sample
   tags:
   - items:
      - created: 2016-01-29T13:40:11Z
      dockerImageReference: 172.30.56.218:5000/test/origin-apache-sample
      generation: 1
      image: vklnld908.int.clsa.com/vipin/test
   tag: latest

Rutas y plantillas

Rutas

En OpenShift, el enrutamiento es un método para exponer el servicio al mundo externo mediante la creación y configuración de un nombre de host accesible externamente. Las rutas y los puntos finales se utilizan para exponer el servicio al mundo externo, desde donde el usuario puede utilizar el nombre de conectividad (DNS) para acceder a la aplicación definida.

En OpenShift, las rutas se crean utilizando enrutadores que implementa el administrador de OpenShift en el clúster. Los enrutadores se utilizan para vincular puertos HTTP (80) y https (443) a aplicaciones externas.

A continuación se muestran los diferentes tipos de protocolo admitidos por las rutas:

• HTTP
• HTTPS
• TSL y enchufe web

Al configurar el servicio, los selectores se utilizan para configurar el servicio y encontrar el punto final utilizando ese servicio. A continuación, se muestra un ejemplo de cómo creamos un servicio y el enrutamiento para ese servicio mediante el uso de un protocolo apropiado.

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {"name": "Openshift-Rservice"},
   "spec": {
      "selector": {"name":"RService-openshift"},
      "ports": [
         {
            "protocol": "TCP",
            "port": 8888,
            "targetPort": 8080
         }
      ]
   }
}

A continuación, ejecute el siguiente comando y se creará el servicio.

$ oc create -f ~/training/content/Openshift-Rservice.json

Así es como se ve el servicio después de su creación.

$ oc describe service Openshift-Rservice

Name:              Openshift-Rservice
Labels:            <none>
Selector:          name = RService-openshift
Type:              ClusterIP
IP:                172.30.42.80
Port:              <unnamed> 8080/TCP
Endpoints:         <none>
Session Affinity:  None
No events.

Cree una ruta para el servicio utilizando el siguiente código.

{
   "kind": "Route",
   "apiVersion": "v1",
   "metadata": {"name": "Openshift-service-route"},
   "spec": {
      "host": "hello-openshift.cloudapps.example.com",
      "to": {
         "kind": "Service",
         "name": "OpenShift-route-service"
      },
      "tls": {"termination": "edge"}
   }
}

Cuando se usa el comando OC para crear una ruta, se crea una nueva instancia de recurso de ruta.

Plantillas

Las plantillas se definen como un objeto estándar en OpenShift que se puede utilizar varias veces. Está parametrizado con una lista de marcadores de posición que se utilizan para crear varios objetos. Esto se puede usar para crear cualquier cosa, desde un pod hasta la creación de redes, para lo cual los usuarios tienen autorización para crear. Se puede crear una lista de objetos, si la plantilla de la interfaz CLI o GUI en la imagen se carga en el directorio del proyecto.

apiVersion: v1
kind: Template
metadata:
   name: <Name of template>
   annotations:
      description: <Description of Tag>
      iconClass: "icon-redis"
      tags: <Tages of image>
objects:
   - apiVersion: v1
   kind: Pod
   metadata:
      name: <Object Specification>
spec:
   containers:
      image: <Image Name>
      name: master
      ports:
      - containerPort: <Container port number>
         protocol: <Protocol>
labels:
   redis: <Communication Type>

Autenticacion y autorizacion

Autenticación

En OpenShift, mientras configura la estructura del maestro y el cliente, el maestro presenta una función incorporada del servidor OAuth. El servidor OAuth se utiliza para generar tokens, que se utiliza para la autenticación en la API. Dado que OAuth viene como una configuración predeterminada para el maestro, tenemos el proveedor de identidad Permitir todo utilizado de forma predeterminada. Hay diferentes proveedores de identidad que se pueden configurar en/etc/openshift/master/master-config.yaml.

Hay diferentes tipos de proveedores de identidad presentes en OAuth.

• Permitir todo
• Negar todo
• HTPasswd
• LDAP
• Autenticación básica

Permitir todo

apiVersion: v1
   kind: Pod
   metadata:
      name: redis-master
   spec:
      containers:
         image: dockerfile/redis
         name: master
      ports:
      - containerPort: 6379
         protocol: TCP
      oauthConfig:
      identityProviders:
      - name: my_allow_provider
         challenge: true
         login: true
      provider:
         apiVersion: v1
         kind: AllowAllPasswordIdentityProvider

Negar todo

apiVersion: v1
kind: Pod
metadata:
   name: redis-master
spec:
   containers:
      image: dockerfile/redis
   name: master
   ports:
   - containerPort: 6379
      protocol: TCP
   oauthConfig:
   identityProviders:
   - name: my_allow_provider
      challenge: true
      login: true
   provider:
      apiVersion: v1
      kind: DenyAllPasswordIdentityProvider

HTPasswd

Para usar HTPasswd, primero debemos configurar Httpd-tools en la máquina maestra y luego configurarlo de la misma manera que lo hicimos con los demás.

identityProviders:
   - name: my_htpasswd_provider
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: HTPasswdPasswordIdentityProvider

Autorización

La autorización es una característica de OpenShift master, que se utiliza para validar a un usuario. Esto significa que verifica al usuario que está intentando realizar una acción para ver si el usuario está autorizado para realizar esa acción en un proyecto determinado. Esto ayuda al administrador a controlar el acceso a los proyectos.

Las políticas de autorización se controlan mediante:

• Rules
• Roles
• Bindings

La evaluación de la autorización se realiza mediante:

• Identity
• Action
• Bindings

Uso de políticas -

• Política de clúster
• Política local

OpenShift consta de dos tipos de medianas para crear e implementar aplicaciones, ya sea mediante GUI o CLI. En este capítulo, usaríamos CLI para crear una nueva aplicación. Utilizaríamos el cliente OC para comunicarnos con el entorno OpenShift.

Crear una nueva aplicación

En OpenShift, hay tres métodos para crear una nueva aplicación.

• De un código fuente
• De una imagen
• De una plantilla

De un código fuente

Cuando intentamos crear una aplicación a partir del código fuente, OpenShift busca un archivo Docker que debería estar presente dentro del repositorio, que define el flujo de compilación de la aplicación. Usaremos oc new-app para crear una aplicación.

Lo primero que debe tener en cuenta al usar un repositorio es que debe apuntar a un origen en el repositorio desde donde OpenShift extraerá el código y lo compilará.

Si el repositorio se clona en la máquina Docker donde está instalado el cliente OC y el usuario está dentro del mismo directorio, entonces se puede crear usando el siguiente comando.

$ oc new-app . <Hear. Denotes current working directory>

A continuación, se muestra un ejemplo de cómo intentar compilar desde un repositorio remoto para una rama específica.

$ oc new-app https://github.com/openshift/Testing-deployment.git#test1

Aquí, test1 es la rama desde la que intentamos crear una nueva aplicación en OpenShift.

Al especificar un archivo Docker en el repositorio, necesitamos definir la estrategia de compilación como se muestra a continuación.

$ oc new-app OpenShift/OpenShift-test~https://github.com/openshift/Testingdeployment.git

De una imagen

Mientras se crea una aplicación con imágenes, las imágenes están presentes en el servidor Docker local, en el repositorio de Docker alojado internamente o en el concentrador de Docker. Lo único que un usuario debe asegurarse es que tiene acceso para extraer imágenes del concentrador sin ningún problema.

OpenShift tiene la capacidad de determinar la fuente utilizada, ya sea una imagen de Docker o un flujo de fuente. Sin embargo, si el usuario lo desea, puede definir explícitamente si es una secuencia de imágenes o una imagen de Docker.

$ oc new-app - - docker-image tomcat

Usando una secuencia de imágenes -

$ oc new-app tomcat:v1

De una plantilla

Las plantillas se pueden utilizar para la creación de una nueva aplicación. Puede ser una plantilla ya existente o crear una nueva plantilla.

El siguiente archivo yaml es básicamente una plantilla que se puede usar para la implementación.

apiVersion: v1
kind: Template
metadata:
   name: <Name of template>
   annotations:
      description: <Description of Tag>
      iconClass: "icon-redis"
      tags: <Tages of image>
objects:
   - apiVersion: v1
   kind: Pod
   metadata:
      name: <Object Specification>
spec:
   containers:
      image: <Image Name>
      name: master
      ports:
      - containerPort: <Container port number>
         protocol: <Protocol>
labels:
   redis: <Communication Type>

Desarrollar e implementar una aplicación web

Desarrollo de una nueva aplicación en OpenShift

Para crear una nueva aplicación en OpenShift, tenemos que escribir un nuevo código de aplicación y construirlo usando los comandos de construcción de OpenShift OC. Como se comentó, tenemos múltiples formas de crear una nueva imagen. Aquí, usaremos una plantilla para construir la aplicación. Esta plantilla creará una nueva aplicación cuando se ejecute con el comando oc new-app.

Se creará la siguiente plantilla: dos aplicaciones frontales y una base de datos. Junto con eso, creará dos nuevos servicios y esas aplicaciones se implementarán en el clúster de OpenShift. Mientras construimos e implementamos una aplicación, inicialmente necesitamos crear un espacio de nombres en OpenShift e implementar la aplicación bajo ese espacio de nombres.

Create a new namespace

$ oc new-project openshift-test --display-name = "OpenShift 3 Sample" --
description = "This is an example project to demonstrate OpenShift v3"

Modelo

{
   "kind": "Template",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-helloworld-sample",
      "creationTimestamp": null,
         "annotations": {
         "description": "This example shows how to create a simple openshift
         application in openshift origin v3",
         "iconClass": "icon-openshift",
         "tags": "instant-app,openshift,mysql"
      }
   }
},

Definiciones de objetos

Secret definition in a template

"objects": [
{
   "kind": "Secret",
   "apiVersion": "v1",
   "metadata": {"name": "dbsecret"},
   "stringData" : {
      "mysql-user" : "${MYSQL_USER}",
      "mysql-password" : "${MYSQL_PASSWORD}"
   }
},

Service definition in a template

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {
      "name": "frontend",
      "creationTimestamp": null
   },
   "spec": {
      "ports": [
         {
            "name": "web",
            "protocol": "TCP",
            "port": 5432,
            "targetPort": 8080,
            "nodePort": 0
         }
      ],
      "selector": {"name": "frontend"},
      "type": "ClusterIP",
      "sessionAffinity": "None"
   },
   "status": {
      "loadBalancer": {}
   }
},

Route definition in a template

{
   "kind": "Route",
   "apiVersion": "v1",
   "metadata": {
      "name": "route-edge",
      "creationTimestamp": null,
      "annotations": {
         "template.openshift.io/expose-uri": "http://{.spec.host}{.spec.path}"
      }
   },
   "spec": {
      "host": "www.example.com",
      "to": {
         "kind": "Service",
         "name": "frontend"
      },
      "tls": {
         "termination": "edge"
      }
   },
   "status": {}
},
{ 
   "kind": "ImageStream",
   "apiVersion": "v1",
   "metadata": {
      "name": "origin-openshift-sample",
      "creationTimestamp": null
   },
   "spec": {},
   "status": {
      "dockerImageRepository": ""
   }
},
{ 
   "kind": "ImageStream",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-22-ubuntu7",
      "creationTimestamp": null 
   },
   "spec": {
      "dockerImageRepository": "ubuntu/openshift-22-ubuntu7"
   },
   "status": {
      "dockerImageRepository": ""
   }
},

Build config definition in a template

{
   "kind": "BuildConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-sample-build",
      "creationTimestamp": null,
      "labels": {name": "openshift-sample-build"}
   },
   "spec": {
      "triggers": [
         { "type": "GitHub",
            "github": {
            "secret": "secret101" } 
         },
         {
            "type": "Generic",
            "generic": {
               "secret": "secret101",
               "allowEnv": true } 
         },
         { 
            "type": "ImageChange",
            "imageChange": {} 
         },
         { "type": "ConfigChange”}
      ],
      "source": {
         "type": "Git",
         "git": {
            "uri": https://github.com/openshift/openshift-hello-world.git } 
      },
      "strategy": {
         "type": "Docker",
         "dockerStrategy": {
            "from": {
               "kind": "ImageStreamTag",
               "name": "openshift-22-ubuntu7:latest” 
            },
            "env": [
               {
                  "name": "EXAMPLE",
                  "value": "sample-app"
               } 
            ]
         }
      },
      "output": {
         "to": {
            "kind": "ImageStreamTag",
            "name": "origin-openshift-sample:latest"
         }
      },
      "postCommit": {
         "args": ["bundle", "exec", "rake", "test"]
      },
      "status": {
         "lastVersion": 0
      }
   }
},

Deployment config in a template

"status": {
   "lastVersion": 0
}
{
   "kind": "DeploymentConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "frontend",
      "creationTimestamp": null
   }
}, 
"spec": {
   "strategy": {
      "type": "Rolling",
      "rollingParams": {
         "updatePeriodSeconds": 1,
         "intervalSeconds": 1,
         "timeoutSeconds": 120,
         "pre": {
            "failurePolicy": "Abort",
            "execNewPod": {
               "command": [
                  "/bin/true"
               ],
               "env": [
                  { 
                     "name": "CUSTOM_VAR1",
                     "value": "custom_value1"
                  }
               ]
            }
         }
      }
   }
}
"triggers": [
   {
      "type": "ImageChange",
      "imageChangeParams": {
         "automatic": true,
         "containerNames": [
            "openshift-helloworld"
         ],
         "from": {
            "kind": "ImageStreamTag",
            "name": "origin-openshift-sample:latest"
         }
      }
   },
   {
      "type": "ConfigChange"
   }
],
"replicas": 2,
"selector": {
   "name": "frontend"
},
"template": {
   "metadata": {
      "creationTimestamp": null,
      "labels": {
         "name": "frontend"
      }
   },
   "spec": {
      "containers": [
         {
            "name": "openshift-helloworld",
            "image": "origin-openshift-sample",
            "ports": [
               { 
                  "containerPort": 8080,
                  "protocol": "TCP” 
               }
            ],
            "env": [
               {
                  "name": "MYSQL_USER",
                  "valueFrom": {
                     "secretKeyRef" : {
                        "name" : "dbsecret",
                        "key" : "mysql-user"
                     }
                  }
               },
               {
                  "name": "MYSQL_PASSWORD",
                  "valueFrom": {
                     "secretKeyRef" : {
                        "name" : "dbsecret",
                        "key" : "mysql-password"
                     }
                  }
               },
               {
                  "name": "MYSQL_DATABASE",
                  "value": "${MYSQL_DATABASE}"
               }
            ],
            "resources": {},
            "terminationMessagePath": "/dev/termination-log",
            "imagePullPolicy": "IfNotPresent",
            "securityContext": {
               "capabilities": {},
               "privileged": false
            }
         }
      ],
      "restartPolicy": "Always",
      "dnsPolicy": "ClusterFirst"
   },
   "status": {}
},

Service definition in a template

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {
      "name": "database",
      "creationTimestamp": null 
   },
   "spec": {
   "ports": [
      {
         "name": "db",
         "protocol": "TCP",
         "port": 5434,
         "targetPort": 3306,
         "nodePort": 0
      } 
   ],
   "selector": {
      "name": "database 
   },
   "type": "ClusterIP",
   "sessionAffinity": "None" },
   "status": {
      "loadBalancer": {}
   }
},

Deployment config definition in a template

{
   "kind": "DeploymentConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "database",
      "creationTimestamp": null
   },
   "spec": {
      "strategy": {
         "type": "Recreate",
         "resources": {}
      },
      "triggers": [
         {
            "type": "ConfigChange"
         }
      ],
      "replicas": 1,
      "selector": {"name": "database"},
      "template": {
         "metadata": {
            "creationTimestamp": null,
            "labels": {"name": "database"}
         },
         "template": {
            "metadata": {
               "creationTimestamp": null,
               "labels": {
                  "name": "database"
               } 
            },
            "spec": {
               "containers": [
                  {
                     "name": "openshift-helloworld-database",
                     "image": "ubuntu/mysql-57-ubuntu7:latest",
                     "ports": [
                        {
                           "containerPort": 3306,
                           "protocol": "TCP" 
                        }
                     ],
                     "env": [
                        {
                           "name": "MYSQL_USER",
                           "valueFrom": {
                              "secretKeyRef" : {
                                 "name" : "dbsecret",
                                 "key" : "mysql-user"
                              }
                           }
                        },
                        {
                           "name": "MYSQL_PASSWORD",
                           "valueFrom": {
                              "secretKeyRef" : {
                                 "name" : "dbsecret",
                                 "key" : "mysql-password"
                              }
                           }
                        },
                        {
                           "name": "MYSQL_DATABASE",
                           "value": "${MYSQL_DATABASE}" 
                        } 
                     ],
                     "resources": {},
                     "volumeMounts": [
                        {
                           "name": "openshift-helloworld-data",
                           "mountPath": "/var/lib/mysql/data"
                        }
                     ],
                     "terminationMessagePath": "/dev/termination-log",
                     "imagePullPolicy": "Always",
                     "securityContext": {
                        "capabilities": {},
                        "privileged": false
                     } 
                  }
               ],
               "volumes": [
                  { 
                     "name": "openshift-helloworld-data",
                     "emptyDir": {"medium": ""} 
                  } 
               ],
               "restartPolicy": "Always",
               "dnsPolicy": "ClusterFirst” 
            } 
         }
      },
      "status": {} 
   },
   "parameters": [
      { 
         "name": "MYSQL_USER",
         "description": "database username",
         "generate": "expression",
         "from": "user[A-Z0-9]{3}",
         "required": true 
      },
      {
         "name": "MYSQL_PASSWORD",
         "description": "database password",
         "generate": "expression",
         "from": "[a-zA-Z0-9]{8}",
         "required": true
      }, 
      {
         "name": "MYSQL_DATABASE",
         "description": "database name",
         "value": "root",
         "required": true 
      } 
   ],
   "labels": {
      "template": "application-template-dockerbuild" 
   } 
}

El archivo de plantilla anterior debe compilarse de una vez. Primero debemos copiar todo el contenido en un solo archivo y nombrarlo como un archivo yaml una vez hecho.

Necesitamos ejecutar el siguiente comando para crear la aplicación.

$ oc new-app application-template-stibuild.json
--> Deploying template openshift-helloworld-sample for "application-template-stibuild.json"

   openshift-helloworld-sample
   ---------
   This example shows how to create a simple ruby application in openshift origin v3
   * With parameters:
      * MYSQL_USER = userPJJ # generated
      * MYSQL_PASSWORD = cJHNK3se # generated
      * MYSQL_DATABASE = root

--> Creating resources with label app = ruby-helloworld-sample ...
   service "frontend" created
   route "route-edge" created
   imagestream "origin-ruby-sample" created
   imagestream "ruby-22-centos7" created
   buildconfig "ruby-sample-build" created
   deploymentconfig "frontend" created
   service "database" created
   deploymentconfig "database" created
   
--> Success
   Build scheduled, use 'oc logs -f bc/ruby-sample-build' to track its progress.
   Run 'oc status' to view your app.

Si deseamos monitorear la compilación, se puede hacer usando -

$ oc get builds

NAME                        TYPE      FROM          STATUS     STARTED         DURATION
openshift-sample-build-1    Source   Git@bd94cbb    Running    7 seconds ago   7s

Podemos verificar las aplicaciones implementadas en OpenShift usando -

$ oc get pods
NAME                            READY   STATUS      RESTARTS   AGE
database-1-le4wx                1/1     Running     0          1m
frontend-1-e572n                1/1     Running     0          27s
frontend-1-votq4                1/1     Running     0          31s
opeshift-sample-build-1-build   0/1     Completed   0          1m

Podemos verificar si los servicios de la aplicación se crean según la definición del servicio usando

$ oc get services
NAME        CLUSTER-IP      EXTERNAL-IP     PORT(S)      SELECTOR          AGE
database    172.30.80.39    <none>         5434/TCP     name=database      1m
frontend    172.30.17.4     <none>         5432/TCP     name=frontend      1m

En OpenShift, tenemos varios métodos para automatizar la canalización de compilación. Para hacer eso, necesitamos crear un recurso BuildConfig para describir el flujo de compilación. El flujo en BuildConfig se puede comparar con la definición de trabajo en la definición de trabajo de Jenkins. Mientras creamos el flujo de construcción, tenemos que elegir la estrategia de construcción.

Archivo BuildConfig

En OpenShift, BuildConfig es un objeto de descanso que se usa para conectarse a la API y luego crear una nueva instancia.

kind: "BuildConfig"
apiVersion: "v1"
metadata:
   name: "<Name of build config file>"
spec:
   runPolicy: "Serial"
   triggers:
   -
      type: "GitHub"
      github:
         secret: "<Secrete file name>"
   - type: "Generic"
   generic:
      secret: "secret101"
   -
   type: "ImageChange"
   source:
      type: "<Source of code>"
      git:
   uri: "https://github.com/openshift/openshift-hello-world"
   dockerfile: "FROM openshift/openshift-22-centos7\nUSER example"
   strategy:
      type: "Source"
      
sourceStrategy:
   from:
      kind: "ImageStreamTag"
      name: "openshift-20-centos7:latest"
   output:
      to:
         kind: "ImageStreamTag"
         name: "origin-openshift-sample:latest"
   postCommit:
      script: "bundle exec rake test"

En OpenShift, hay cuatro tipos de estrategias de compilación.

• Estrategia de fuente a imagen
• Estrategia de Docker
• Estrategia personalizada
• Estrategia de canalización

Estrategia de fuente a imagen

Permite crear imágenes de contenedores a partir del código fuente. En este flujo, el código real se descarga primero en el contenedor y luego se compila dentro de él. El código compilado se implementa dentro del mismo contenedor y la imagen se crea a partir de ese código.

strategy:
   type: "Source"
   sourceStrategy:
      from:
         kind: "ImageStreamTag"
         name: "builder-image:latest"
      forcePull: true

Hay múltiples políticas estratégicas.

• Forcepull
• Construcciones incrementales
• Construcciones externas

Estrategia de Docker

En este flujo, OpenShift usa Dockerfile para crear la imagen y luego cargar las imágenes creadas en el registro de Docker.

strategy:
   type: Docker
   dockerStrategy:
      from:
         kind: "ImageStreamTag"
         name: "ubuntu:latest"

La opción de archivo Docker se puede utilizar en varias ubicaciones a partir de la ruta del archivo, sin caché y forzar extracción.

• Desde imagen
• Ruta de Dockerfile
• Sin caché
• Fuerza de tracción

Estrategia personalizada

Este es uno de los diferentes tipos de estrategias de construcción, en el que no existe tal obligación de que el resultado de la construcción sea una imagen. Se puede comparar con un trabajo de estilo libre de Jenkins. Con esto, podemos crear Jar, rpm y otros paquetes.

strategy:
   type: "Custom"
   customStrategy:
      from:
         kind: "DockerImage"
         name: "openshift/sti-image-builder"

Consiste en múltiples estrategias de construcción.

• Exponer el zócalo de Docker
• Secrets
• Fuerza de tracción

Estrategia de canalización

La estrategia de canalización se utiliza para crear canalizaciones de compilación personalizadas. Esto se usa básicamente para implementar el flujo de trabajo en la canalización. Este flujo de compilación utiliza un flujo de canalización de compilación personalizado con el lenguaje Groovy DSL. OpenShift creará un trabajo de canalización en Jenkins y lo ejecutará. Este flujo de tubería también se puede utilizar en Jenkins. En esta estrategia, usamos Jenkinsfile y lo agregamos en la definición de buildconfig.

Strategy:
   type: "JenkinsPipeline"
   jenkinsPipelineStrategy:
   jenkinsfile: "node('agent') {\nstage 'build'\nopenshiftBuild(buildConfig: 'OpenShift-build', showBuildLogs: 'true')\nstage 'deploy'\nopenshiftDeploy(deploymentConfig: 'backend')\n}"

Using build pipeline

kind: "BuildConfig"
apiVersion: "v1"
metadata:
   name: "test-pipeline"
spec:
   source:
      type: "Git"
      git:
         uri: "https://github.com/openshift/openshift-hello-world"
   strategy:
      type: "JenkinsPipeline"
      jenkinsPipelineStrategy:
         jenkinsfilePath: <file path repository>

La CLI de OpenShift se utiliza para administrar aplicaciones OpenShift desde la línea de comandos. OpenShift CLI tiene la capacidad de administrar el ciclo de vida de las aplicaciones de un extremo a otro. En general, usaríamos OC, que es un cliente de OpenShift para comunicarnos con OpenShift.

Configuración de la CLI de OpenShift

Para configurar el cliente OC en un sistema operativo diferente, debemos seguir una secuencia de pasos diferente.

Cliente OC para Windows

Step 1 - Descarga el oc cli desde el siguiente enlace https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2

Step 2 - Descomprima el paquete en una ruta de destino en la máquina.

Step 3 - Edite la variable de entorno de ruta del sistema.

C:\Users\xxxxxxxx\xxxxxxxx>echo %PATH%

C:\oraclexe\app\oracle\product\10.2.0\server\bin;C:\Program Files 
(x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Program Files 
(x86)\AMD APP\bin\x86_64;C:\Program Files (x86)\AMD APP\bin\x86;

C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\
v1.0\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files 
(x86)\ATI Technologies\ATI.ACE\C

ore-Static;C:\Program Files\Intel\Intel(R) Management Engine 
Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine 
Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;

Step 4 - Validar la configuración de OC en Windows.

C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc version
oc v3.6.0-alpha.2+3c221d5
kubernetes v1.6.1+5115d708d7
features: Basic-Auth

Cliente OC para Mac OS X

Podemos descargar los binarios de configuración de Mac OS para la misma ubicación que para Windows y luego descomprimirlos en una ubicación y establecer una ruta de ejecución en la variable de entorno PATH.

Alternatively

Podemos usar Home brew y configurarlo usando el siguiente comando.

$ brew install openshift-cli

Cliente OC para Linux

Debajo de la misma página, tenemos el archivo tar para la instalación de Linux que se puede usar para la instalación. Más tarde, se puede establecer una variable de ruta que apunte a esa ubicación ejecutable en particular.

https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2

Descomprime el archivo tar usando el siguiente comando.

$ tar –xf < path to the OC setup tar file >

Ejecute el siguiente comando para verificar la autenticación.

C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc login
Server [https://localhost:8443]:

Archivos de configuración de CLI

El archivo de configuración OC CLI se usa para administrar múltiples conexiones de servidor OpenShift y mecanismos de autenticación. Este archivo de configuración también se usa para almacenar y administrar múltiples perfiles y para cambiar entre ellos. Un archivo de configuración normal tiene el siguiente aspecto.

$ oc config view
apiVersion: v1
clusters:
   - cluster:
      server: https://vklnld908.int.example.com
   name: openshift
   
contexts:
- context:
   cluster: openshift
   namespace: testproject
   user: alice
   name: alice
current-context: alice
kind: Config
preferences: {}
users:
- name: vipin
   user:
      token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

Configuración del cliente CLI

Para configurar la credencial de usuario

$ oc config set-credentials <user_nickname>
[--client-certificate = <path/to/certfile>] [--client-key=<path/to/keyfile>]
[--token = <bearer_token>] [--username = <basic_user>] [--password = <basic_password>]

Para configurar clúster

$ oc config set-cluster <cluster_nickname> [--server = <master_ip_or_fqdn>]
[--certificate-authority = <path/to/certificate/authority>]
[--api-version = <apiversion>] [--insecure-skip-tls-verify = true]

Ejemplo

$ oc config set-credentials vipin --token = ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

Para establecer el contexto

$ oc config set-context <context_nickname> [--cluster = <cluster_nickname>]
[--user = <user_nickname>] [--namespace = <namespace>]

Perfiles CLI

En un solo archivo de configuración de CLI, podemos tener varios perfiles en los que cada perfil tiene una configuración de servidor OpenShift diferente, que luego se puede usar para cambiar entre diferentes perfiles de CLI.

apiVersion: v1
clusters: --→ 1
- cluster:
   insecure-skip-tls-verify: true
   server: https://vklnld908.int.example.com:8443
   name: vklnld908.int.example.com:8443
- cluster:
   insecure-skip-tls-verify: true
   server: https://vklnld1446.int.example.com:8443
   name: vklnld1446.int.example.com:8443
contexts: ---→ 2
- context:
   cluster: vklnld908.int.example.com:8443
   namespace: openshift-project
   user: vipin/vklnld908.int.example.com:8443
   name: openshift-project/vklnld908.int.example.com:8443/vipin
- context:
   cluster: vklnld908.int.example.com:8443
   namespace: testing-project
   user: alim/vklnld908.int.example.com:8443
   name: testproject-project/openshift1/alim
current-context: testing-project/vklnld908.int.example.com:8443/vipin - 3
kind: Config
preferences: {}

users:
- name: vipin/vklnld908.int.example.com:8443
user: ---→ 4
   token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

En la configuración anterior, podemos ver que está dividida en cuatro secciones principales a partir del clúster que define dos instancias de máquinas maestras OpenShift. La segunda sección de contexto define dos contextos llamados vipin y alim. El contexto actual define qué contexto está actualmente en uso. Se puede cambiar a otro contexto o perfil, si cambiamos la definición aquí. Finalmente, se define la definición de usuario y su token de autenticación que en nuestro caso es vipin.

Si queremos verificar el perfil actual en uso, se puede hacer usando -

$ oc status oc status In project testing Project (testing-project) $ oc project
Using project "testing-project" from context named "testing-
project/vklnld908.int.example.com:8443/vipin" on server "https://vklnld908.int.example.com:8443".

Si queremos cambiar a otra CLI, podemos hacerlo desde la línea de comandos usando el siguiente comando.

$ oc project openshift-project
Now using project "Openshift-project" on server "
https://vklnld908.int.example.com:8443".

Usando el comando anterior, podemos cambiar entre perfiles. En cualquier momento, si deseamos ver la configuración, podemos usar el comando $ oc config view.

OpenShift CLI es capaz de realizar toda la configuración, administración, adición e implementación básicas y avanzadas de aplicaciones.

Podemos realizar diferentes tipos de operaciones usando comandos OC. Este cliente lo ayuda a desarrollar, construir, implementar y ejecutar sus aplicaciones en cualquier plataforma compatible con OpenShift o Kubernetes. También incluye los comandos administrativos para administrar un clúster bajo el subcomando 'adm'.

Comandos básicos

La siguiente tabla enumera los comandos OC básicos.

No Señor.	Comandos y descripción
1	Types Introducción a conceptos y tipos
2	Login Iniciar sesión en un servidor
3	new-project Solicita un nuevo proyecto
4	new-app Crear una nueva aplicación
5	Status Mostrar una descripción general del proyecto actual
6	Project Cambiar a otro proyecto
7	Projects Mostrar proyectos existentes
8	Explain Documentación de recursos
9	Cluster Iniciar y detener el clúster de OpenShift

Iniciar sesión

Inicie sesión en su servidor y guarde el inicio de sesión para su uso posterior. Los usuarios nuevos del cliente deben ejecutar este comando para conectarse a un servidor, establecer una sesión autenticada y guardar una conexión al archivo de configuración. La configuración predeterminada se guardará en su directorio de inicio en ".kube / config".

La información necesaria para iniciar sesión, como el nombre de usuario y la contraseña, un token de sesión o los detalles del servidor, se pueden proporcionar a través de banderas. Si no se proporciona, el comando solicitará la entrada del usuario según sea necesario.

Usage

oc login [URL] [options]

Example

# Log in interactively
oc login

# Log in to the given server with the given certificate authority file
oc login localhost:8443 --certificate-authority = /path/to/cert.crt

# Log in to the given server with the given credentials (will not prompt interactively)
oc login localhost:8443 --username = myuser --password=mypass

Opciones -

-p, --password = " - Contraseña, se le pedirá si no se proporciona

-u, --username = " - Nombre de usuario, se le preguntará si no se proporciona

--certificate-authority = "- Camino a un certificado. archivo para la autoridad certificadora

--insecure-skip-tls-verify = false- Si es verdadero, no se comprobará la validez del certificado del servidor. Esto hará que sus conexiones HTTPS sean inseguras

--token = " - Token de portador para autenticación en el servidor API

Para obtener los detalles completos sobre cualquier comando, use el oc <Command Name> --help mando.

Compilar e implementar comandos

La siguiente tabla enumera los comandos de construcción e implementación.

No Señor.	Comandos y descripción
1	Rollout Gestionar una implementación de Kubernetes o una implementación de OpenShift
2	Deploy Ver, iniciar, cancelar o reintentar una implementación
3	Rollback Revertir parte de una aplicación al estado anterior
4	new-build Cree una nueva configuración de construcción
5	start-build Iniciar una nueva construcción
6	cancel-build Cancelar compilaciones en ejecución, pendientes o nuevas
7	import-image Importa imágenes de un registro de Docker
8	Tag Etiquetar las imágenes existentes en secuencias de imágenes

Comandos de administración de aplicaciones

La siguiente tabla enumera los comandos de administración de aplicaciones.

No Señor.	Comandos y descripción
1	Get Mostrar uno o varios recursos
2	Describe Mostrar detalles de un recurso específico o un grupo de recursos
3	Edit Editar un recurso en el servidor
4	Set Comandos que ayudan a establecer características específicas en objetos
5	Label Actualizar las etiquetas de un recurso
6	Annotate Actualizar las anotaciones en un recurso
7	Expose Exponer una aplicación replicada como servicio o ruta
8	Delete Eliminar uno o más recursos
9	Scale Cambiar la cantidad de pods en una implementación
10	Autoscale Autoescalar una configuración de implementación, implementación, replicación, controlador o conjunto de réplicas
11	Secrets Gestionar secretos
12	Serviceaccounts Administra cuentas de servicio en tu proyecto

Comandos de resolución de problemas y depuración

La siguiente tabla enumera los comandos de resolución de problemas y depuración.

No Señor.	Comandos y descripción
1	logs Imprime los registros de un recurso
2	Rsh Iniciar una sesión de shell en un pod
3	Rsync Copie archivos entre el sistema de archivos local y un pod
4	port-forward Reenviar uno o más puertos locales a un pod
5	Debug Lanzar una nueva instancia de un pod para depurar
6	Exec Ejecutar un comando en un contenedor
7	Procy Ejecute un proxy para el servidor API de Kubernetes
9	Attach Adjuntar a un contenedor en funcionamiento
10	Run Ejecute una imagen particular en el clúster
11	Cp Copie archivos y directorios desde y hacia contenedores

Comandos avanzados

La siguiente tabla enumera los comandos avanzados.

No Señor.	Comandos y descripción
1	adm Herramientas para administrar un clúster
2	create Crea un recurso por nombre de archivo o stdin
3	replace Reemplazar un recurso por nombre de archivo o stdin
4	apply Aplicar una configuración a un recurso por nombre de archivo o stdin
5	patch Actualizar los campos de un recurso mediante el parche de combinación estratégica
6	process Procesar una plantilla en una lista de recursos
7	export Exportar recursos para que puedan utilizarse en otros lugares
8	extract Extraer secretos o mapas de configuración al disco
9	idle Recursos escalables inactivos
10	observe Observar cambios en los recursos y reaccionar a ellos (experimental)
11	policy Administrar la política de autorización
12	auth Inspeccionar autorización
13	convert Convertir archivos de configuración entre diferentes versiones de API
14	import Comandos que importan aplicaciones

Configuración de comandos

La siguiente tabla enumera los comandos de configuración.

No Señor.	Comandos y descripción
1	Logout Finalizar la sesión actual del servidor
2	Config Cambiar los archivos de configuración para el cliente
3	Whoami Devolver información sobre la sesión actual
4	Completion Código de finalización del shell de salida para el shell especificado (bash o zsh)

OpenShift utiliza dos métodos de instalación para configurar el clúster de OpenShift.

• Método de instalación rápida
• Método de configuración avanzada

Configuración de clúster

Método de instalación rápida

Este método se utiliza para ejecutar una configuración de instalación de clúster no obtenida rápida. Para utilizar este método, primero debemos instalar el instalador. Esto se puede hacer ejecutando el siguiente comando.

Interactive method

$ atomic-openshift-installer install

Esto es útil cuando se desea ejecutar una configuración interactiva.

Unattended installation method

Este método se utiliza cuando se desea configurar un método de instalación desatendido, en el que el usuario puede definir un archivo yaml de configuración y colocarlo en ~/.config/openshift/con el nombre de installer.cfg.yml. Luego, se puede ejecutar el siguiente comando para instalar el–u tag.

$ atomic-openshift-installer –u install

De forma predeterminada, utiliza el archivo de configuración ubicado en ~/.config/openshift/. Ansible, por otro lado, se utiliza como copia de seguridad de la instalación.

version: v2
variant: openshift-enterprise
variant_version: 3.1
ansible_log_path: /tmp/ansible.log

deployment:
   ansible_ssh_user: root
   hosts:
   - ip: 172.10.10.1
   hostname: vklnld908.int.example.com
   public_ip: 24.222.0.1
   public_hostname: master.example.com
   roles:
      - master
      - node
   containerized: true
   connect_to: 24.222.0.1
   
   - ip: 172.10.10.2
   hostname: vklnld1446.int.example.com
   public_ip: 24.222.0.2
   public_hostname: node1.example.com
   roles:
      - node
   connect_to: 10.0.0.2
   
   - ip: 172.10.10.3
   hostname: vklnld1447.int.example.com
   public_ip: 10..22.2.3
   public_hostname: node2.example.com
   roles:
      - node
   connect_to: 10.0.0.3

roles:
   master:
      <variable_name1>: "<value1>"
      <variable_name2>: "<value2>"
   node:
      <variable_name1>: "<value1>"

Aquí, tenemos una variable específica de rol, que se puede definir si se desea configurar alguna variable específica.

Una vez hecho esto, podemos verificar la instalación usando el siguiente comando.

$ oc get nodes
NAME                    STATUS    AGE
master.example.com      Ready     10d
node1.example.com       Ready     10d
node2.example.com       Ready     10d

Instalación avanzada

La instalación avanzada se basa completamente en la configuración de Ansible, donde está presente la configuración completa del host y la definición de variables con respecto a la configuración del maestro y el nodo. Contiene todos los detalles sobre la configuración.

Una vez que tenemos la configuración y el libro de jugadas está listo, simplemente podemos ejecutar el siguiente comando para configurar el clúster.

$ ansible-playbook -i inventry/hosts ~/openshift-ansible/playbooks/byo/config.yml

Agregar hosts a un clúster

Podemos agregar un host al clúster usando -

• Herramienta de instalación rápida
• Método de configuración avanzada

Quick installation toolfunciona tanto en modo interactivo como no interactivo. Utilice el siguiente comando.

$ atomic-openshift-installer -u -c </path/to/file> scaleup

El formato de escalado de la apariencia del archivo de configuración de la aplicación se puede utilizar para agregar tanto el maestro como el nodo.

Método de configuración avanzada

En este método, actualizamos el archivo host de Ansible y luego agregamos un nuevo nodo o detalles del servidor en este archivo. El archivo de configuración tiene el siguiente aspecto.

[OSEv3:children]
masters
nodes
new_nodes
new_master

En el mismo archivo de hosts de Ansible, agregue detalles variables sobre el nuevo nodo como se muestra a continuación.

[new_nodes]
vklnld1448.int.example.com openshift_node_labels = "{'region': 'primary', 'zone': 'east'}"

Finalmente, usando el archivo de host actualizado, ejecute la nueva configuración e invoque el archivo de configuración para realizar la instalación usando el siguiente comando.

$ ansible-playbook -i /inventory/hosts /usr/share/ansible/openshift-ansible/playbooks/test/openshift-node/scaleup.yml

Administrar registros de clústeres

El registro del clúster de OpenShift no es más que los registros que se generan desde el maestro y las máquinas de nodo del clúster. Estos pueden administrar cualquier tipo de registro, comenzando por el registro del servidor, el registro maestro, el registro del contenedor, el registro del pod, etc. Existen múltiples tecnologías y aplicaciones presentes para la gestión del registro del contenedor.

Pocas de las herramientas se encuentran en la lista, que se pueden implementar para la gestión de registros.

• Fluentd
• ELK
• Kabna
• Nagios
• Splunk

ELK stack- Esta pila es útil al intentar recopilar los registros de todos los nodos y presentarlos en un formato sistemático. La pila de ELK se divide principalmente en tres categorías principales.

ElasticSearch - Principalmente responsable de recopilar información de todos los contenedores y colocarla en una ubicación central.

Fluentd - Se utiliza para alimentar los troncos recolectados al motor del contenedor de búsqueda elástica.

Kibana - Una interfaz gráfica utilizada para presentar los datos recopilados como información útil en una interfaz gráfica.

Un punto clave a tener en cuenta es que cuando este sistema se implementa en el clúster, comienza a recopilar registros de todos los nodos.

Diagnósticos de registro

OpenShift tiene incorporado oc adm dignosticscomando con OC que se puede utilizar para analizar múltiples situaciones de error. Esta herramienta se puede utilizar desde el maestro como administrador de clúster. Esta utilidad es muy útil para solucionar problemas y reconocer problemas conocidos. Esto se ejecuta en el cliente maestro y los nodos.

Si se ejecuta sin ningún parámetro o indicador, buscará los archivos de configuración del cliente, el servidor y las máquinas de nodo y los utilizará para el diagnóstico. Se pueden ejecutar los diagnósticos individualmente pasando los siguientes argumentos:

• AggregatedLogging
• AnalyzeLogs
• ClusterRegistry
• ClusterRoleBindings
• ClusterRoles
• ClusterRouter
• ConfigContexts
• DiagnosticPod
• MasterConfigCheck
• MasterNode
• MetricsApiProxy
• NetworkCheck
• NodeConfigCheck
• NodeDefinitions
• ServiceExternalIPs
• UnitStatus

Uno simplemente puede ejecutarlos con el siguiente comando.

$ oc adm diagnostics <DiagnosticName>

Actualizar un clúster

La actualización del clúster implica actualizar varias cosas dentro del clúster y hacer que el clúster se actualice con nuevos componentes y actualizaciones. Esto implica:

• Actualización de componentes maestros
• Actualización de los componentes del nodo
• Actualización de políticas
• Actualización de rutas
• Actualización del flujo de imágenes

Para realizar todas estas actualizaciones, primero necesitamos instalar instaladores rápidos o utilidades. Para eso, necesitamos actualizar las siguientes utilidades:

• atomic-openshift-utils
• atomic-openshift-excluder
• atomic-openshift-docker-excluder
• paquete etcd

Antes de comenzar la actualización, necesitamos hacer una copia de seguridad de etcd en la máquina maestra, lo que se puede hacer usando los siguientes comandos.

$ ETCD_DATA_DIR = /var/lib/origin/openshift.local.etcd
$ etcdctl backup \ --data-dir $ETCD_DATA_DIR \
   --backup-dir $ETCD_DATA_DIR.bak.<date>

Actualización de componentes maestros

En OpenShift master, comenzamos la actualización actualizando el archivo etcd y luego pasamos a Docker. Finalmente, ejecutamos el ejecutador automático para colocar el clúster en la posición requerida. Sin embargo, antes de comenzar la actualización, primero debemos activar los paquetes atómicos openshift en cada uno de los maestros. Esto se puede hacer usando los siguientes comandos.

Step 1 - Eliminar paquetes atomic-openshift

$ atomic-openshift-excluder unexclude

Step 2 - Actualizar etcd en todos los maestros.

$ yum update etcd

Step 3 - Reinicie el servicio de etcd y compruebe si se ha iniciado correctamente.

$ systemctl restart etcd
$ journalctl -r -u etcd

Step 4 - Actualice el paquete Docker.

$ yum update docker

Step 5 - Reinicie el servicio Docker y compruebe si está correctamente activado.

$ systemctl restart docker $ journalctl -r -u docker

Step 6 - Una vez hecho esto, reinicie el sistema con los siguientes comandos.

$ systemctl reboot $ journalctl -r -u docker

Step 7 - Finalmente, ejecute el ejecutador atómico para que los paquetes vuelvan a la lista de exclusiones de yum.

$ atomic-openshift-excluder exclude

No existe tal obligación para actualizar la política, solo necesita actualizarse si se recomienda, lo que se puede verificar con el siguiente comando.

$ oadm policy reconcile-cluster-roles

En la mayoría de los casos, no es necesario actualizar la definición de política.

Actualización de los componentes del nodo

Una vez que se completa la actualización maestra, podemos comenzar a actualizar los nodos. Una cosa a tener en cuenta es que el período de actualización debe ser corto para evitar cualquier tipo de problema en el clúster.

Step 1 - Elimine todos los paquetes atómicos de OpenShift de todos los nodos donde desee realizar la actualización.

$ atomic-openshift-excluder unexclude

Step 2 - A continuación, desactive la programación de nodos antes de la actualización.

$ oadm manage-node <node name> --schedulable = false

Step 3 - Replica todo el nodo del host actual al otro host.

$ oadm drain <node name> --force --delete-local-data --ignore-daemonsets

Step 4 - Actualice la configuración de Docker en el host.

$ yum update docker

Step 5 - Reinicie el servicio Docker y luego inicie el nodo de servicio Docker.

$systemctl restart docker $ systemctl restart atomic-openshift-node

Step 6 - Compruebe si ambos se iniciaron correctamente.

$ journalctl -r -u atomic-openshift-node

Step 7 - Una vez completada la actualización, reinicie la máquina del nodo.

$ systemctl reboot
$ journalctl -r -u docker

Step 8 - Vuelva a habilitar la programación en los nodos.

$ oadm manage-node <node> --schedulable.

Step 9 - Ejecute el ejecutador atomic-openshift para recuperar el paquete OpenShift en el nodo.

$ atomic-openshift-excluder exclude

Step 10 - Por último, compruebe si todos los nodos están disponibles.

$ oc get nodes

NAME                 STATUS   AGE
master.example.com   Ready    12d
node1.example.com    Ready    12d
node2.example.com    Ready    12d

El ajuste de escala automático es una función de OpenShift en la que las aplicaciones implementadas pueden escalar y hundirse cuando sea necesario según determinadas especificaciones. En la aplicación OpenShift, el ajuste de escala automático también se conoce como ajuste de escala automático de pod. Hay dostypes of application scaling como sigue.

Escala vertical

El escalado vertical se trata de agregar más y más potencia a una sola máquina, lo que significa agregar más CPU y disco duro. Es un método antiguo de OpenShift que ahora no es compatible con las versiones de OpenShift.

Escala horizontal

Este tipo de escalado es útil cuando existe la necesidad de manejar más solicitudes aumentando el número de máquinas.

En OpenShift, hay two methods to enable the scaling feature.

• Usando el archivo de configuración de implementación
• Mientras ejecuta la imagen

Uso del archivo de configuración de implementación

En este método, la función de escalado se habilita mediante un archivo yaml de configuración de implementación. Para ello, el comando OC autoscale se utiliza con un número mínimo y máximo de réplicas, que debe ejecutarse en cualquier momento del clúster. Necesitamos una definición de objeto para la creación del escalador automático. A continuación, se muestra un ejemplo de archivo de definición de escalador automático de pod.

apiVersion: extensions/v1beta1
kind: HorizontalPodAutoscaler
metadata:
   name: database
spec:
   scaleRef:
      kind: DeploymentConfig
      name: database
      apiVersion: v1
      subresource: scale
   minReplicas: 1
   maxReplicas: 10
   cpuUtilization:
      targetPercentage: 80

Una vez que tengamos el archivo en su lugar, debemos guardarlo con el formato yaml y ejecutar el siguiente comando para la implementación.

$ oc create –f <file name>.yaml

Mientras ejecuta la imagen

También se puede escalar automáticamente sin el archivo yaml, utilizando lo siguiente oc autoscale comando en la línea de comando oc.

$ oc autoscale dc/database --min 1 --max 5 --cpu-percent = 75
deploymentconfig "database" autoscaled

Este comando también generará un tipo de archivo similar que luego se puede usar como referencia.

Estrategias de implementación en OpenShift

La estrategia de implementación en OpenShift define un flujo de implementación con diferentes métodos disponibles. En OpenShift, los siguientes son losimportant types of deployment strategies.

• Estrategia rodante
• Recrear estrategia
• Estrategia personalizada

A continuación se muestra un ejemplo de archivo de configuración de implementación, que se utiliza principalmente para la implementación en nodos de OpenShift.

kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
   name: "database"
spec:
   template:
      metadata:
         labels:
            name: "Database1"
spec:
   containers:
      - name: "vipinopenshifttest"
         image: "openshift/mongoDB"
         ports:
            - containerPort: 8080
               protocol: "TCP"
replicas: 5
selector:
   name: "database"
triggers:
- type: "ConfigChange"
- type: "ImageChange"
   imageChangeParams:
      automatic: true
      containerNames:
         - "vipinopenshifttest"
      from:
         kind: "ImageStreamTag"
         name: "mongoDB:latest"
   strategy:
      type: "Rolling"

En el archivo Deploymentconfig anterior, tenemos la estrategia como Rolling.

Podemos usar el siguiente comando OC para la implementación.

$ oc deploy <deployment_config> --latest

Estrategia rodante

La estrategia progresiva se utiliza para actualizaciones continuas o implementación. Este proceso también admite enlaces de ciclo de vida, que se utilizan para inyectar código en cualquier proceso de implementación.

strategy:
   type: Rolling
   rollingParams:
      timeoutSeconds: <time in seconds>
      maxSurge: "<definition in %>"
      maxUnavailable: "<Defintion in %>"
      pre: {}
      post: {}

Recrear estrategia

Esta estrategia de implementación tiene algunas de las características básicas de la estrategia de implementación continua y también admite el enlace del ciclo de vida.

strategy:
   type: Recreate
   recreateParams:
      pre: {}
      mid: {}
      post: {}

Estrategia personalizada

Esto es muy útil cuando se desea proporcionar su propio proceso o flujo de implementación. Todas las personalizaciones se pueden hacer según el requisito.

strategy:
   type: Custom
   customParams:
      image: organization/mongoDB
      command: [ "ls -l", "$HOME" ]
      environment:
         - name: VipinOpenshiftteat
         value: Dev1

En este capítulo, cubriremos temas como cómo administrar un nodo, configurar una cuenta de servicio, etc.

Configuración de maestro y nodo

En OpenShift, necesitamos usar el comando de inicio junto con OC para iniciar un nuevo servidor. Al iniciar un nuevo maestro, necesitamos usar el maestro junto con el comando de inicio, mientras que al iniciar el nuevo nodo, necesitamos usar el nodo junto con el comando de inicio. Para hacer esto, necesitamos crear archivos de configuración para el maestro y para los nodos. Podemos crear un archivo de configuración básica para el maestro y el nodo usando el siguiente comando.

Para archivo de configuración maestro

$ openshift start master --write-config = /openshift.local.config/master

Para el archivo de configuración del nodo

$ oadm create-node-config --node-dir = /openshift.local.config/node-<node_hostname> --node = <node_hostname> --hostnames = <hostname>,<ip_address>

Una vez que ejecutemos los siguientes comandos, obtendremos los archivos de configuración base que se pueden usar como punto de partida para la configuración. Posteriormente, podemos tener el mismo archivo para arrancar los nuevos servidores.

apiLevels:
- v1beta3
- v1
apiVersion: v1
assetConfig:
   logoutURL: ""
   masterPublicURL: https://172.10.12.1:7449
   publicURL: https://172.10.2.2:7449/console/
      servingInfo:
         bindAddress: 0.0.0.0:7449
         certFile: master.server.crt
         clientCA: ""
keyFile: master.server.key
   maxRequestsInFlight: 0
   requestTimeoutSeconds: 0
controllers: '*'
corsAllowedOrigins:
- 172.10.2.2:7449
- 127.0.0.1
- localhost
dnsConfig:
   bindAddress: 0.0.0.0:53
etcdClientInfo:
   ca: ca.crt
   certFile: master.etcd-client.crt
   keyFile: master.etcd-client.key
   urls:
   - https://10.0.2.15:4001
etcdConfig:
   address: 10.0.2.15:4001
   peerAddress: 10.0.2.15:7001
   peerServingInfo:
      bindAddress: 0.0.0.0:7001
      certFile: etcd.server.crt
      clientCA: ca.crt
      keyFile: etcd.server.key
   servingInfo:
      bindAddress: 0.0.0.0:4001
      certFile: etcd.server.crt
      clientCA: ca.crt
      keyFile: etcd.server.key
   storageDirectory: /root/openshift.local.etcd
etcdStorageConfig:
   kubernetesStoragePrefix: kubernetes.io
   kubernetesStorageVersion: v1
   openShiftStoragePrefix: openshift.io
   openShiftStorageVersion: v1
imageConfig:
   format: openshift/origin-${component}:${version}
   latest: false
kind: MasterConfig
kubeletClientInfo:
   ca: ca.crt
   certFile: master.kubelet-client.crt
   keyFile: master.kubelet-client.key
   port: 10250
kubernetesMasterConfig:
   apiLevels:
   - v1beta3
   - v1
   apiServerArguments: null
   controllerArguments: null
   masterCount: 1
   masterIP: 10.0.2.15
   podEvictionTimeout: 5m
   schedulerConfigFile: ""
   servicesNodePortRange: 30000-32767
   servicesSubnet: 172.30.0.0/16
   staticNodeNames: []
masterClients:
   externalKubernetesKubeConfig: ""
   openshiftLoopbackKubeConfig: openshift-master.kubeconfig
masterPublicURL: https://172.10.2.2:7449
networkConfig:
   clusterNetworkCIDR: 10.1.0.0/16
   hostSubnetLength: 8
   networkPluginName: ""
   serviceNetworkCIDR: 172.30.0.0/16
oauthConfig:
   assetPublicURL: https://172.10.2.2:7449/console/
   grantConfig:
      method: auto
   identityProviders:
   - challenge: true
   login: true
   name: anypassword
   provider:
      apiVersion: v1
      kind: AllowAllPasswordIdentityProvider
   masterPublicURL: https://172.10.2.2:7449/
   masterURL: https://172.10.2.2:7449/
   sessionConfig:
      sessionMaxAgeSeconds: 300
      sessionName: ssn
      sessionSecretsFile: ""
   tokenConfig:
      accessTokenMaxAgeSeconds: 86400
      authorizeTokenMaxAgeSeconds: 300
policyConfig:
   bootstrapPolicyFile: policy.json
   openshiftInfrastructureNamespace: openshift-infra
   openshiftSharedResourcesNamespace: openshift
projectConfig:
   defaultNodeSelector: ""
   projectRequestMessage: ""
   projectRequestTemplate: ""
   securityAllocator:
      mcsAllocatorRange: s0:/2
      mcsLabelsPerProject: 5
      uidAllocatorRange: 1000000000-1999999999/10000
routingConfig:
   subdomain: router.default.svc.cluster.local
serviceAccountConfig:
   managedNames:
   - default
   - builder
   - deployer
   
masterCA: ca.crt
   privateKeyFile: serviceaccounts.private.key
   privateKeyFile: serviceaccounts.private.key
   publicKeyFiles:
   - serviceaccounts.public.key
servingInfo:
   bindAddress: 0.0.0.0:8443
   certFile: master.server.crt
   clientCA: ca.crt
   keyFile: master.server.key
   maxRequestsInFlight: 0
   requestTimeoutSeconds: 3600

Archivos de configuración de nodo

allowDisabledDocker: true
apiVersion: v1
dnsDomain: cluster.local
dnsIP: 172.10.2.2
dockerConfig:
   execHandlerName: native
imageConfig:
   format: openshift/origin-${component}:${version}
   latest: false
kind: NodeConfig
masterKubeConfig: node.kubeconfig
networkConfig:
   mtu: 1450
   networkPluginName: ""
nodeIP: ""
nodeName: node1.example.com

podManifestConfig:
   path: "/path/to/pod-manifest-file"
   fileCheckIntervalSeconds: 30
servingInfo:
   bindAddress: 0.0.0.0:10250
   certFile: server.crt
   clientCA: node-client-ca.crt
   keyFile: server.key
volumeDirectory: /root/openshift.local.volumes

Así es como se ven los archivos de configuración del nodo. Una vez que tengamos estos archivos de configuración en su lugar, podemos ejecutar el siguiente comando para crear el servidor maestro y el nodo.

$ openshift start --master-config = /openshift.local.config/master/master-
config.yaml --node-config = /openshift.local.config/node-<node_hostname>/node-
config.yaml

Gestión de nodos

En OpenShift, tenemos la utilidad de línea de comandos OC que se usa principalmente para realizar todas las operaciones en OpenShift. Podemos usar los siguientes comandos para administrar los nodos.

Para listar un nodo

$ oc get nodes
NAME                             LABELS
node1.example.com     kubernetes.io/hostname = vklnld1446.int.example.com
node2.example.com     kubernetes.io/hostname = vklnld1447.int.example.com

Describir detalles sobre un nodo

$ oc describe node <node name>

Eliminar un nodo

$ oc delete node <node name>

Listado de pods en un nodo

$ oadm manage-node <node1> <node2> --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]

Evaluar pods en un nodo

$ oadm manage-node <node1> <node2> --evacuate --dry-run [--pod-selector=<pod_selector>]

Autenticación de configuración

En OpenShift master, hay un servidor OAuth integrado, que se puede usar para administrar la autenticación. Todos los usuarios de OpenShift obtienen el token de este servidor, lo que les ayuda a comunicarse con la API de OpenShift.

Hay diferentes tipos de niveles de autenticación en OpenShift, que se pueden configurar junto con el archivo de configuración principal.

• Permitir todo
• Negar todo
• HTPasswd
• LDAP
• Autenticación básica
• Encabezado de solicitud

Mientras definimos la configuración maestra, podemos definir la política de identificación donde podemos definir el tipo de política que deseamos utilizar.

Permitir todo

Permitir todo

oauthConfig:
   ...
   identityProviders:
   - name: Allow_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: AllowAllPasswordIdentityProvider

Negar todo

Esto negará el acceso a todos los nombres de usuario y contraseñas.

oauthConfig:
   ...
   identityProviders:
   - name: deny_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: DenyAllPasswordIdentityProvider

HTPasswd

HTPasswd se utiliza para validar el nombre de usuario y la contraseña con una contraseña de archivo cifrada.

Para generar un archivo cifrado, el siguiente es el comando.

$ htpasswd </path/to/users.htpasswd> <user_name>

Usando el archivo cifrado.

oauthConfig:
   ...
   identityProviders:
   - name: htpasswd_authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: HTPasswdPasswordIdentityProvider
         file: /path/to/users.htpasswd

Proveedor de identidad LDAP

Se utiliza para la autenticación LDAP, en la que el servidor LDAP desempeña un papel clave en la autenticación.

oauthConfig:
   ...
   identityProviders:
   - name: "ldap_authontication"
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: LDAPPasswordIdentityProvider
         attributes:
            id:
            - dn
            email:
            - mail
            name:
            - cn
            preferredUsername:
            - uid
         bindDN: ""
         bindPassword: ""
         ca: my-ldap-ca-bundle.crt
         insecure: false
         url: "ldap://ldap.example.com/ou=users,dc=acme,dc=com?uid"

Autenticación básica

Se utiliza cuando la validación del nombre de usuario y la contraseña se realiza frente a una autenticación de servidor a servidor. La autenticación está protegida en la URL base y se presenta en formato JSON.

oauthConfig:
   ...
   identityProviders:
   - name: my_remote_basic_auth_provider
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: BasicAuthPasswordIdentityProvider
         url: https://www.vklnld908.int.example.com/remote-idp
         ca: /path/to/ca.file
         certFile: /path/to/client.crt
         keyFile: /path/to/client.key

Configurar una cuenta de servicio

Las cuentas de servicio proporcionan una forma flexible de acceder a la API de OpenShift exponiendo el nombre de usuario y la contraseña para la autenticación.

Habilitación de una cuenta de servicio

La cuenta de servicio utiliza un par de claves públicas y privadas para la autenticación. La autenticación a la API se realiza mediante una clave privada y la valida con una clave pública.

ServiceAccountConfig:
   ...
   masterCA: ca.crt
   privateKeyFile: serviceaccounts.private.key
   publicKeyFiles:
   - serviceaccounts.public.key
   - ...

Crear una cuenta de servicio

Utilice el siguiente comando para crear una cuenta de servicio

$ Openshift cli create service account <name of server account>

Trabajar con proxy HTTP

En la mayor parte del entorno de producción, el acceso directo a Internet está restringido. No están expuestos a Internet o están expuestos a través de un proxy HTTP o HTTPS. En un entorno OpenShift, esta definición de máquina proxy se establece como una variable de entorno.

Esto se puede hacer agregando una definición de proxy en los archivos maestro y de nodo ubicados en /etc/sysconfig. Esto es similar a lo que hacemos con cualquier otra aplicación.

Máquina maestra

/ etc / sysconfig / openshift-master

HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=master.vklnld908.int.example.com

Máquina de nodo

/ etc / sysconfig / openshift-node

HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=master.vklnld908.int.example.com

Una vez hecho esto, necesitamos reiniciar las máquinas maestra y nodo.

Para Docker Pull

/ etc / sysconfig / docker

HTTP_PROXY = http://USERNAME:[email protected]:8080/
HTTPS_PROXY = https://USERNAME:[email protected]:8080/
NO_PROXY = master.vklnld1446.int.example.com

Para hacer que un pod se ejecute en un entorno de proxy, se puede hacer usando:

containers:
- env:
   - name: "HTTP_PROXY"
      value: "http://USER:PASSWORD@:10.0.1.1:8080"

El comando de entorno OC se puede utilizar para actualizar el entorno env existente.

Almacenamiento OpenShift con NFS

En OpenShift, el concepto de volumen persistente y reclamos de volumen persistente forma almacenamiento persistente. Este es uno de los conceptos clave en los que se crea el primer volumen persistente y luego se reclama ese mismo volumen. Para esto, necesitamos tener suficiente capacidad y espacio en disco en el hardware subyacente.

apiVersion: v1
kind: PersistentVolume
metadata:
   name: storage-unit1
spec:
   capacity:
      storage: 10Gi
   accessModes:
   - ReadWriteOnce
   nfs:
      path: /opt
      server: 10.12.2.2
   persistentVolumeReclaimPolicy: Recycle

A continuación, utilizando el comando OC create, cree un volumen persistente.

$ oc create -f storage-unit1.yaml

persistentvolume " storage-unit1 " created

Reclamando el volumen creado.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
   name: Storage-clame1
spec:
   accessModes:
      - ReadWriteOnce
   resources:
      requests:
         storage: 5Gi

Crea el reclamo.

$ oc create -f Storage-claim1.yaml
persistentvolume " Storage-clame1 " created

Gestión de usuarios y roles

La administración de usuarios y roles se utiliza para administrar usuarios, su acceso y controles en diferentes proyectos.

Crear un usuario

Se pueden utilizar plantillas predefinidas para crear nuevos usuarios en OpenShift.

kind: "Template"
apiVersion: "v1"
parameters:
   - name: vipin
   required: true
objects:
   - kind: "User"
   apiVersion: "v1"
   metadata:
   name: "${email}" - kind: "Identity" apiVersion: "v1" metadata: name: "vipin:${email}"
   providerName: "SAML"
   providerUserName: "${email}" - kind: "UserIdentityMapping" apiVersion: "v1" identity: name: "vipin:${email}"
user:
   name: "${email}"

Utilice oc create –f <nombre de archivo> para crear usuarios.

$ oc create –f vipin.yaml

Utilice el siguiente comando para eliminar un usuario en OpenShift.

$ oc delete user <user name>

Limitar el acceso de los usuarios

ResourceQuotas y LimitRanges se utilizan para limitar los niveles de acceso de los usuarios. Se utilizan para limitar las vainas y contenedores en el clúster.

apiVersion: v1
kind: ResourceQuota
metadata:
   name: resources-utilization
spec:
   hard:
      pods: "10"

Creando la cotización usando la configuración anterior

$ oc create -f resource-quota.yaml –n –Openshift-sample

Describiendo la cotización del recurso

$ oc describe quota resource-quota  -n  Openshift-sample
Name:              resource-quota
Namespace:                              Openshift-sample
Resource           Used                  Hard
--------           ----                  ----
pods                3                    10

La definición de los límites de contenedores se puede utilizar para limitar los recursos que van a utilizar los contenedores desplegados. Se utilizan para definir las limitaciones máximas y mínimas de determinados objetos.

Limitaciones del proyecto de usuario

Esto se usa básicamente para la cantidad de proyectos que un usuario puede tener en cualquier momento. Básicamente, se realizan definiendo los niveles de usuario en categorías de bronce, plata y oro.

Primero debemos definir un objeto que contenga el valor de cuántos proyectos puede tener una categoría de bronce, plata y oro. Estos deben realizarse en el archivo master-confif.yaml.

admissionConfig:
   pluginConfig:
      ProjectRequestLimit:
         configuration:
            apiVersion: v1
            kind: ProjectRequestLimitConfig
            limits:
            - selector:
               level: platinum
            - selector:
               level: gold
            maxProjects: 15
            - selector:
               level: silver
            maxProjects: 10
            - selector:
               level: bronze
            maxProjects: 5

Reinicie el servidor maestro.

Asignar un usuario a un nivel particular.

$ oc label user vipin level = gold

Sacar al usuario de la etiqueta, si es necesario.

$ oc label user <user_name> level-

Agregar roles a un usuario.

$ oadm policy add-role-to-user 
      
        <user_name> 
      

Eliminar el rol de un usuario.

$ oadm policy remove-role-from-user 
      
        <user_name> 
      

Agregar una función de clúster a un usuario.

$ oadm policy add-cluster-role-to-user 
      
        <user_name> 
      

Eliminar una función de clúster de un usuario.

$ oadm policy remove-cluster-role-from-user 
      
        <user_name> 
      

Agregar un rol a un grupo.

$ oadm policy add-role-to-user 
      
        <user_name> 
      

Eliminar un rol de un grupo.

$ oadm policy remove-cluster-role-from-user 
      
        <user_name> 
      

Agregar una función de clúster a un grupo.

$ oadm policy add-cluster-role-to-group 
      
        <groupname> 
      

Eliminar una función de clúster de un grupo.

$ oadm policy remove-cluster-role-from-group <role> <groupname>

Usuario para la administración de clústeres

Este es uno de los roles más poderosos donde el usuario tiene la capacidad de administrar un clúster completo desde la creación hasta la eliminación de un clúster.

$ oadm policy add-role-to-user admin <user_name> -n <project_name>

Usuario con la máxima potencia

$ oadm policy add-cluster-role-to-user cluster-admin <user_name>

OpenShift se basa en Docker y Kubernetes. Todos los contenedores están construidos sobre el clúster de Docker, que es básicamente el servicio de Kubernetes sobre las máquinas Linux, utilizando la función de orquestaciones de Kubernetes.

En este proceso, construimos Kubernetes master que controla todos los nodos e implementa los contenedores en todos los nodos. La función principal de Kubernetes es controlar el flujo de implementación y el clúster de OpenShift mediante un tipo diferente de archivo de configuración. Al igual que en Kubernetes, usamos kubctl de la misma manera que usamos la utilidad de línea de comandos OC para construir e implementar contenedores en los nodos del clúster.

A continuación se muestran los diferentes tipos de archivos de configuración utilizados para la creación de diferentes tipos de objetos en el clúster.

• Images
• POD
• Service
• Controlador de replicación
• Conjunto de réplicas
• Deployment

Imagenes

Las imágenes de Kubernetes (Docker) son los componentes clave de la infraestructura en contenedores. A partir de ahora, Kubernetes solo admiteDockerimágenes. Cada contenedor de un pod tiene su imagen de Docker ejecutándose en su interior.

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> 1
   spec:
   containers:
- name: neo4j-server ------------------------> 2
image: <Name of the Docker image>----------> 3
imagePullPolicy: Always ------------->4
command: [“echo”, “SUCCESS”] -------------------> 5

VAINA

Un pod es una colección de contenedores y su almacenamiento dentro de un nodo de un clúster de Kubernetes. Es posible crear una vaina con varios contenedores en su interior. A continuación, se muestra un ejemplo de cómo mantener un contenedor de base de datos y un contenedor de interfaz web en el mismo pod.

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
      image: tomcat: 8.0
      ports:
- containerPort: 7500
imagePullPolicy: Always

Servicio

Un servicio se puede definir como un conjunto lógico de pods. Se puede definir como una abstracción en la parte superior del pod que proporciona una única dirección IP y un nombre DNS mediante el cual se puede acceder a los pods. Con Service, es muy fácil administrar la configuración del equilibrio de carga. Ayuda a los POD a escalar muy fácilmente.

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
   - port: 8080
      targetPort: 31999

Controlador de replicación

El controlador de replicación es una de las características clave de Kubernetes, que es responsable de administrar el ciclo de vida del pod. Es responsable de asegurarse de que se estén ejecutando números específicos de réplicas de pods en cualquier momento.

apiVersion: v1
kind: ReplicationController
metadata:
   name: Tomcat-ReplicationController
spec:
   replicas: 3
   template:
   metadata:
      name: Tomcat-ReplicationController
   labels:
      app: App
      component: neo4j
   spec:
      containers:
      - name: Tomcat
      image: tomcat: 8.0
      ports:
      - containerPort: 7474

Juego de réplicas

El conjunto de réplicas asegura cuántas réplicas de pod se deben ejecutar. Puede considerarse como un reemplazo del controlador de replicación.

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   selector:
      matchLables:
      tier: Backend
   matchExpression:
      - { key: tier, operation: In, values: [Backend]}
   
   app: App
   component: neo4j
spec:
   containers:
   - name: Tomcat-
image: tomcat: 8.0
   ports:
containerPort: 7474

Despliegue

Las implementaciones se actualizan y las versiones superiores del controlador de replicación. Administran la implementación de conjuntos de réplicas, que también es una versión mejorada del controlador de réplica. Tienen la capacidad de actualizar el conjunto de réplicas y también pueden retroceder a la versión anterior.

apiVersion: extensions/v1beta1 --------------------->1
kind: Deployment --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   template:
      metadata:
lables:
   app: Tomcat-ReplicaSet
   tier: Backend
spec:
   containers:
name: Tomcat-
   image: tomcat: 8.0
   ports:
   - containerPort: 7474

Todos los archivos de configuración se pueden usar para crear sus respectivos objetos de Kubernetes.

$ Kubectl create –f <file name>.yaml

Los siguientes comandos se pueden utilizar para conocer los detalles y la descripción de los objetos de Kubernetes.

For POD

$ Kubectl get pod <pod name> $ kubectl delete pod <pod name>
$ kubectl describe pod <pod name>

For Replication Controller

$ Kubectl get rc <rc name>
$ kubectl delete rc <rc name> $ kubectl describe rc <rc name>

For Service

$ Kubectl get svc <svc name> $ kubectl delete svc <svc name>
$ kubectl describe svc <svc name>

Para obtener más detalles sobre cómo trabajar con Docker y Kubernetes, visite nuestro tutorial de Kubernetes utilizando el siguiente enlace kubernetes .

La seguridad de OpenShift es principalmente una combinación de dos componentes que maneja principalmente las restricciones de seguridad.

• Restricciones del contexto de seguridad (SCC)
• Cuenta de servicio

Restricciones del contexto de seguridad (SCC)

Básicamente se utiliza para la restricción de pod, lo que significa que define las limitaciones de un pod, en cuanto a las acciones que puede realizar y todas las cosas a las que puede acceder en el clúster.

OpenShift proporciona un conjunto de SCC predefinidos que el administrador puede utilizar, modificar y ampliar.

$ oc get scc
NAME              PRIV   CAPS  HOSTDIR  SELINUX    RUNASUSER         FSGROUP   SUPGROUP  PRIORITY
anyuid            false   []   false    MustRunAs  RunAsAny          RunAsAny  RunAsAny  10
hostaccess        false   []   true     MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>
hostmount-anyuid  false   []   true     MustRunAs  RunAsAny          RunAsAny  RunAsAny  <none>
nonroot           false   []   false    MustRunAs  MustRunAsNonRoot  RunAsAny  RunAsAny  <none>
privileged        true    []   true     RunAsAny   RunAsAny          RunAsAny  RunAsAny  <none>
restricted        false   []   false    MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>

Si uno desea utilizar cualquier scc predefinido, puede hacerlo simplemente agregando el usuario o el grupo al grupo scc.

$ oadm policy add-user-to-scc <scc_name> <user_name> $ oadm policy add-group-to-scc <scc_name> <group_name>

Cuenta de servicio

Las cuentas de servicio se utilizan básicamente para controlar el acceso a la API maestra de OpenShift, a la que se llama cuando se activa un comando o una solicitud desde cualquiera de las máquinas maestras o nodos.

Cada vez que una aplicación o un proceso requiera una capacidad que no sea otorgada por el SCC restringido, deberá crear una cuenta de servicio específica y agregar la cuenta al SCC respectivo. Sin embargo, si un SCC no se adapta a sus requisitos, entonces es mejor crear un nuevo SCC específico para sus requisitos en lugar de utilizar el que mejor se ajuste. Al final, configúrelo para la configuración de implementación.

$ oc create serviceaccount Cadmin $ oc adm policy add-scc-to-user vipin -z Cadmin

Seguridad del contenedor

En OpenShift, la seguridad de los contenedores se basa en el concepto de cuán segura es la plataforma de contenedores y dónde se ejecutan los contenedores. Hay muchas cosas que entran en escena cuando hablamos de la seguridad de los contenedores y de lo que hay que cuidar.

Image Provenance - Existe un sistema de etiquetado seguro que identifica de forma exacta e incontrovertible el origen de los contenedores que se ejecutan en el entorno de producción.

Security Scanning - Un escáner de imágenes comprueba automáticamente todas las imágenes en busca de vulnerabilidades conocidas.

Auditing - El entorno de producción se audita periódicamente para garantizar que todos los contenedores se basan en contenedores actualizados y que tanto los hosts como los contenedores están configurados de forma segura.

Isolation and Least Privilege- Los contenedores se ejecutan con los recursos y privilegios mínimos necesarios para funcionar con eficacia. No pueden interferir indebidamente con el anfitrión u otros contenedores.

Runtime Threat Detection - Una capacidad que detecta amenazas activas contra aplicaciones en contenedores en tiempo de ejecución y responde automáticamente a ellas.

Access Controls - Los módulos de seguridad de Linux, como AppArmor o SELinux, se utilizan para hacer cumplir los controles de acceso.

Existen pocos métodos clave mediante los cuales se archiva la seguridad de los contenedores.

• Controlar el acceso a través de oAuth
• Mediante consola web de autoservicio
• Por Certificados de plataforma

Controlar el acceso a través de OAuth

En este método, la autenticación del acceso de control de API se archiva obteniendo un token seguro para la autenticación a través de servidores OAuth, que viene incorporado en la máquina maestra OpenShift. Como administrador, tiene la capacidad de modificar la configuración del servidor OAuth.

Para obtener más detalles sobre la configuración del servidor OAuth, consulte el Capítulo 5 de este tutorial.

A través de la consola web de autoservicio

Esta función de seguridad de la consola web está incorporada en la consola web OpenShift. Esta consola asegura que todos los equipos que trabajan juntos no tengan acceso a otros entornos sin autenticación. El maestro multi-telnet en OpenShift tiene las siguientes características de seguridad:

• La capa TCL está habilitada
• Utiliza el certificado x.509 para la autenticación
• Asegura la configuración de etcd en la máquina maestra

Por Certificados de Plataforma

En este método, los certificados para cada host se configuran durante la instalación a través de Ansible. Como utiliza el protocolo de comunicación HTTPS a través de Rest API, necesitamos una conexión segura TCL a diferentes componentes y objetos. Estos son certificados predefinidos, sin embargo, incluso se puede tener un certificado personalizado instalado en el clúster del maestro para acceder. Durante la configuración inicial del maestro, los certificados personalizados se pueden configurar anulando los certificados existentes usandoopenshift_master_overwrite_named_certificates parámetro.

Example

openshift_master_named_certificates = [{"certfile": "/path/on/host/to/master.crt", 
"keyfile": "/path/on/host/to/master.key", 
"cafile": "/path/on/host/to/mastercert.crt"}]

Para obtener más detalles sobre cómo generar certificados personalizados, visite el siguiente enlace:

https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux

Seguridad de la red

En OpenShift, las redes definidas por software (SDN) se utilizan para la comunicación. El espacio de nombres de red se utiliza para cada pod en el clúster, donde cada pod obtiene su propia IP y un rango de puertos para obtener tráfico de red. Con este método, se pueden aislar los pods debido a que no se puede comunicar con los pods del otro proyecto.

Aislar un proyecto

El administrador del clúster puede hacer esto mediante lo siguiente oadm command desde CLI.

$ oadm pod-network isolate-projects <project name 1> <project name 2>

Esto significa que los proyectos definidos anteriormente no pueden comunicarse con otros proyectos del clúster.

Seguridad de volumen

La seguridad del volumen claramente significa proteger el PV y el PVC de los proyectos en el clúster OpenShift. Hay principalmente cuatro secciones para controlar el acceso a los volúmenes en OpenShift.

• Grupos suplementarios
• fsGroup
• runAsUser
• seLinuxOptions

Grupos suplementarios: los grupos suplementarios son grupos regulares de Linux. Cuando un proceso se ejecuta en el sistema, se ejecuta con una identificación de usuario y una identificación de grupo. Estos grupos se utilizan para controlar el acceso al almacenamiento compartido.

Verifique el montaje NFS usando el siguiente comando.

# showmount -e <nfs-server-ip-or-hostname>
Export list for f21-nfs.vm:
/opt/nfs *

Verifique los detalles de NFS en el servidor de montaje usando el siguiente comando.

# cat /etc/exports
/opt/nfs *(rw,sync,no_root_squash)
...
# ls -lZ /opt/nfs -d
drwxrws---. nfsnobody 2325 unconfined_u:object_r:usr_t:s0 /opt/nfs
# id nfsnobody
uid = 65534(nfsnobody) gid = 454265(nfsnobody) groups = 454265(nfsnobody)

Se puede acceder a / opt / nfs / export mediante UID454265 y el grupo 2325.

apiVersion: v1
kind: Pod
...
spec:
   containers:
   - name: ...
      volumeMounts:
      - name: nfs
         mountPath: /usr/share/...
   securityContext:
      supplementalGroups: [2325]
   volumes:
   - name: nfs
      nfs:
      server: <nfs_server_ip_or_host>
      path: /opt/nfs

fsGroup

fsGroup significa el grupo del sistema de archivos que se utiliza para agregar grupos complementarios de contenedores. El ID de grupo suplementario se usa para el almacenamiento compartido y fsGroup se usa para el almacenamiento en bloque.

kind: Pod
spec:
   containers:
   - name: ...
   securityContext:
      fsGroup: 2325

runAsUser

runAsUser utiliza el ID de usuario para la comunicación. Esto se utiliza para definir la imagen del contenedor en la definición de pod. Se puede utilizar un solo usuario de ID en todos los contenedores, si es necesario.

Mientras se ejecuta el contenedor, el ID definido coincide con el ID del propietario en la exportación. Si el ID especificado se define en el exterior, se vuelve global para todos los contenedores del pod. Si se define con un pod específico, se vuelve específico para un solo contenedor.

spec:
   containers:
   - name: ...
      securityContext:
         runAsUser: 454265