openshitf

 PaaS (Platform as a Service)= concepto relacionado a la computación en la nube, para el desarrollo de aplicaciones sin preocuparse de la infra estructura, por ejemplo si necesitamos mas capacidad pagamos mas para ciertos momentos de mas demanda. 

no nos preocupamos de las actualizaciones, sistema operativo, instalaciones.....etc. solo nos preocupamos de montar nuestra aplicación y que se encuentre operativa

al tener nuestra app en la nube obtenemos elasticidad, pago por uso bajo demanda.

por ejemplo: Amazon Azure, Google App Engine, Oracle Cloud Plataform, para desarrolladores: heroku, openshift...

Saas (software como servicio)=concepto de ofrecer un software solo para usarlo,sin preocuparnos de su mantenimiento u infraestructura nos importa que funcione y provea el servicio necesario...es elástico o sea es expansible. No nos preocupamos de las actualizaciones...seguridad, cortafuegos solo lo usamos, por ejemplo el correo de Google

IaaS (infraestructura como servicio)

maquinas virtuales, almacenamiento, redes virtuales....el usuario recibe como servicio un almacenamiento

Desplegando aplicaciones en contenedores

• los contenedores comparten el núcleo del anfitrión
• componentes de docker: 
• docker engine, 
• docker client,
• docker registry
• existen dos tipos de contenedores, contenedores de sistemas, ejemplo LXC y contenedores de aplicaciones, por ejemplo docker.
• guardamos en volúmenes para persistir la información y no perderla al momento de reiniciar el contenedor

Kubernete

nos permite orquestar nuestros contenedores, salió el 2015 por parte de Google

kubernete trabaja con container.io, de esta manera puede trabajar con otras tecnologias diferentes a docker

recursos de kubernate

• pod= unidad mínima, puede ejecutar uno o varios contenedores
• replicaSet=asegura que haya siempre un numero de replicas ejecutándose de un pod determinado. de esta forma si deseamos aumentar el numero de pod's estos se distribuyen en el clúster y se crean y eliminan de forma automática. Obtenemos tolerancia a errores, estabilidad dinámica.
• deployment: nos permite manejar los replicaSets, obtenemos actualizaciones continuas y despliegues automáticos. de esta forma nos aahorramos el trabajo crear una nueva imagen cada vez que hacemos una actualización a nuestro código, la imagen se crea de forma automática.
• service: nos permite acceder a los pods de manera interna y externa
• ingress: nos permite implementar un proxy inverso para el acceso a los distintos servicios, obtenemos la funcionalidad de balanceo de carga

OPENSHIFT

Pensado para desarrolladores

Openshift desde la version 3 utiliza kubernate, antes utilizaba otra tecnologia

openshif puede construir las imagenes de diferentes formas (source to image), es una mejora pero tambien se le da mas responsabilidades por lo que utiliza mas recursos

Forma de utilizar Openshift

(OKD) Podemos descargarlo e instalarlo 

Versión Online free: , cluster gestionado por redhat compartido

version dedicated: La versión online pero dedicado para la organización

Openshift container platform: Openshit instalado en nuestros servidores pero administrado por redhat

Catalogo de tecnologías: lenguajes,template,etc

unidad organizativa básica= Proyectos, paracesido al namespace. El proyecto engloba todos los recursos

minishift:Para instalar openshift localmente

Despliegue primera aplicacion

source to image= permite crear imagen via openshitf con repositorio git: 

• creara un built que clonara el repositorio para generar la imagen y creara otro buid para desplegar la aplicacion
• lo desplegara en un pod
• crea el servicio de acceso al pod
• crea las rutas para servicio

Api openshift:

Openshift pone a dispocision un frontend para getionar el cluster, pero tambien se puede hacer directamente desde la API de openshift

aplication->Deployment=getiona los replicaset que crean los pod

Cada vez que se realiza un buid los pod son eliminados y se crean otros nuevos

Cada pod tiene un servicio y algunos servicios tienen rutas para que puedan entrar desde el exterior. Por ejemplo si mi pod se conecta a otro pod DB, lo hará desde un servicio, pero el pod DB no tendrá ruta, ya que no es necesario que se ingrese de forma remota, si no que entre los pod vía servicio.

Tolerancia fallos: cuando se cae o elimina un pod, automaticamnete se crea para reponer el servicio

escalabilidad: se puede definir fácilmente la cantidad de pod vinculados al servicio, estos realizan un balanceo de carga entre los pod creados.

Rollback= al momento de hacer algun cambio en el codigo, se realiza el cambio en el repositorio y luego se crea un build para que clone y despliegue nuevamente el servicio

build automatico (WebHuck)= Desde el repositorio se puede automatizar la generacion del build en openshift, para esto se debe configurar el repositorio y la sección build de openshift

Despliegue de aplicaciones

Nos permite desplegar aplicaciones desde una imagen ya existente, dockerfile, plantillas, pipeline o desde el código fuente y openshift genera los artefactos necesarios, el despliegue se puede realizar desde diferentes enfoques:

• Deployment= igual que kubernet, al parecer es temporal
• DeploymentConfig= propio de openshift, al parcer tiene persistencia
• Deploymen servles = te cobra solo por lo que utilizas, al parecer se adapta a requerimiento

Recursos

ImageStream: propio de openshift es una referencia(puntero) a una imagen tanto interna como externa

Buildconfig: Se ejecuta cuando se construye la imagen

Catalogo de aplicaciones: coleccion de software preempaquetado que se pueden instalar y utilizar en un cluster openshift

Deployment vs DeploymentConfig

el deployment config es propio de opneshift

deployment config cuenta con un replication controller para gestionar el pod deploy, quien contiene los pods

deploymen maneja varios replicaset en cambio el deplymenconfig los gestiona a travez del pod deploy, de esta forma deployment maneja varios replicaset en cambio deployment config tiene un solo pod deploy y puede tener como maximo un replicationController

Deploymnet config prefiere la cosistencia y deployment la disponibilidad

DeploymentConfig permiten volver automaticamente a la ultima version operativa

Disparadores o actualizacion de despliegue: deploymentconfig se actualiza por vario motivos (cambio configuracion,imagen,etc), en los deployment solo en el cambio de configuracion.

Los deployment config pueden ejecutar script en su ciclo de vida ademas de configurar estrategias personalizadas de despliegues

En los deployment se puede pausar el despliegue en los deployment config no

Estrategias de despliegue

Especifica como sera el paso de pod antiguos a pod nuevos al momento de actualizar un deployment o deployment config.

Variables de entorno

se pueden definir desde un config map o secrets, el secret es un poco mas seguro para guardar datos mas seguros, se codifican en base64