OpenShift v3 (Mega Tutorial) – Parte 3 – CLI

OpenShift

OpenShift v3 – CLI

OpenShift pone a nuestra disposición dos maneras principales de conectar a su API: la línea de comandos y la consola Web. Vamos a empezar viendo el CLI (Command Line Interface).

CLI

OpenShift nos ofrece dos utilidades CLI para la gestión de nuestro clúster:

  • oc: es la herramienta básica, pensada para la creación y gestión de los proyectos y las aplicaciones. Es, por así decirlo, la utilidad para los desarrolladores.
  • oadm: esta herramienta administra el clúster. Permite gestionar ciertos recursos, límites, políticas y seguridad.

Ambas herramientas se encuentran disponibles en cualquier host de nuestro cluster, pero también pueden descargarse y utilizarse en una máquina remota. Existen dos versiones: únicamente oc, para plataformas Linux/Mac/Windows, y oc+oadm para Linux exclusivamente. Pueden descargarse aquí.

GoLang

GoLang es un lenguaje de programación, creado por Google, utilizado por el proyecto Kubernetes; OpenShift, al hacer uso de él, está escrito en Go, y sus herramientas de líneas de comandos también. Estas herramientas CLI interactúan con el API de OpenShift mediante llamadas REST con el protocolo HTTP.

 

Autenticación

Para poder hacer uso de las llamadas al API es necesario estar autenticados. El mecanismo de autenticación se define en el fichero de configuración principal del Master que se encuentra en /etc/origin/master/master-config.yaml, en la sección oauthConfig:

oauthConfig:
 assetPublicURL: https://master.osc.test:8443/console/
 grantConfig:
   method: auto
 identityProviders:
 - challenge: true
   login: true
   mappingMethod: claim
   name: deny_all
   provider:
     apiVersion: v1
     kind: DenyAllPasswordIdentityProvider
 masterCA: ca-bundle.crt
 masterPublicURL: https://master.osc.test:8443
 masterURL: https://master.osc.test:8443
 sessionConfig:
   sessionMaxAgeSeconds: 3600
   sessionName: ssn
   sessionSecretsFile: /etc/origin/master/session-secrets.yaml
 tokenConfig:
   accessTokenMaxAgeSeconds: 86400
   authorizeTokenMaxAgeSeconds: 500

En la sección provider->kind es donde se define el mecanismo. Por defecto está configurado DenyAllPasswordIdentityProvider, que actúa permitiendo acceso al  API al usuario root de la máquina Master que hace uso de un certificado para acreditarse en el API.

Existen varios mecanismos de autenticación entre los que se encuentran:

  • HTTP: hace uso de un fichero htpasswd
  • LDAP: que se conectará a un servidor LDAP
  • Keystone: hace uso de los keystone de autenticación de OpenStack
  • Google: permite loguearnos con la cuenta de Google
  • Github: permite loguearnos con la cuenta de Github

Hay varios más que no he citado pero que se encuentran disponibles. En este tutorial, y por simplificar, haré uso de HTTP, así que veremos cómo configurarlo. Más información en la documentación de OpenShift.

 

HTPasswdPasswordIdentityProvider

El primer paso que necesitamos es instalar, en Master, las herramientas que nos permitirán crear el fichero htpasswd.

yum install -y httpd-tools

Creamos el fichero htpasswd con el usuario demo

htpasswd -c /etc/origin/master/.htpasswd demo
New password: <demo>
Re-type new password: <demo>
Adding password for user demo

Editamos el fichero de configuración:

vim /etc/origin/master/master-config.yaml
...
oauthConfig:
 assetPublicURL: https://master.osc.test:8443/console/
 grantConfig:
   method: auto
 identityProviders:
 - challenge: true
   login: true
   mappingMethod: claim
   name: my_htpasswd 
   provider:
     apiVersion: v1
     kind: HTPasswdPasswordIdentityProvider
     file: /etc/origin/master/.htpasswd
 masterCA: ca-bundle.crt
 masterPublicURL: https://master.osc.test:8443
...

Hay que reiniciar el servicio para que los cambios se apliquen

systemctl restart origin-master

Para poder jugar sin problemas, voy a descargar en la máquina Gateway la herramienta oc y me loguearé con el usuario que hemos creado, así simulamos un usuario en su máquina remota.

cd /tmp/
curl -L https://github.com/openshift/origin/releases/download/v1.2.1/openshift-origin-client-tools-v1.2.1-5e723f6-linux-64bit.tar.gz|tar xz
mkdir ~/bin
mv openshift-origin-client-tools-v1.2.1-5e723f6-linux-64bit/oc ~/bin
rm -rf openshift-origin-client-tools-v1.2.1-5e723f6-linux-64bit/
cd ~
oc login https://master.osc.test:8443
The server uses a certificate signed by an unknown authority.
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
Use insecure connections? (y/n): y
Authentication required for https://master.osc.test:8443 (openshift)
Username: demo
Password: demo
Login successful.

You don't have any projects. You can try to create a new project, by running

 $ oc new-project <projectname>

Welcome! See 'oc help' to get started.

Ahora vamos a seguir un poco los pasos que nos indican para crear un proyecto, y después nuestra primera, y muy simple, aplicación en PHP:

oc new-project test
Now using project "test" on server "https://master.osc.test:8443".

You can add applications to this project with the 'new-app' command. For example, try:

 $ oc new-app centos/ruby-22-centos7~https://github.com/openshift/ruby-hello-world.git

to build a new hello-world application in Ruby.

oc new-app centos/ruby-22-centos7~https://github.com/openshift/ruby-hello-world.git
--> Found Docker image 62e0acf (7 days old) from Docker Hub for "centos/ruby-22-centos7"

 Ruby 2.2 
 -------- 
 Platform for building and running Ruby 2.2 applications

 Tags: builder, ruby, ruby22

 * An image stream will be created as "ruby-22-centos7:latest" that will track the source image
 * A source build using source code from https://github.com/openshift/ruby-hello-world.git will be created
 * The resulting image will be pushed to image stream "ruby-hello-world:latest"
 * Every time "ruby-22-centos7:latest" changes a new build will be triggered
 * This image will be deployed in deployment config "ruby-hello-world"
 * Port 8080/tcp will be load balanced by service "ruby-hello-world"
 * Other containers can access this service through the hostname "ruby-hello-world"

--> Creating resources with label app=ruby-hello-world ...
 imagestream "ruby-22-centos7" created
 imagestream "ruby-hello-world" created
 buildconfig "ruby-hello-world" created
 deploymentconfig "ruby-hello-world" created
 service "ruby-hello-world" created
--> Success
 Build scheduled, use 'oc logs -f bc/ruby-hello-world' to track its progress.
 Run 'oc status' to view your app.
oc get pods
NAME                     READY  STATUS      RESTARTS    AGE
ruby-hello-world-1-build 0/1    Completed   0           2m
ruby-hello-world-1-cakcb 1/1    Running     0           10s


oc get svc
NAME               CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
ruby-hello-world   172.30.140.4   <none>        8080/TCP   3m

Como todavía no tenemos acceso a la consola Web, y tampoco hemos configurado una IP externa, para poder acceder al contenido de nuestra aplicación lo haremos mediante el comando curl y desde uno de nuestros nodos. Este ejemplo está ejecutado en Master

curl -s 172.30.140.4:8080|head -n 20
<!DOCTYPE html>
<html>
<head>
 <!-- Latest compiled and minified CSS -->
 <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.0/css/bootstrap.min.css">

 <!-- Optional theme -->
 <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.0/css/bootstrap-theme.min.css">

 <!-- Latest compiled and minified JavaScript -->
 <script src="//code.jquery.com/jquery-1.11.0.min.js"></script>
 <script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.0/js/bootstrap.min.js"></script>

  <title>;Hello from OpenShift v3!</title>
</head>
<body>
 <div class="page-header" align=center>
 <h1> Welcome to an OpenShift v3 Demo App! </h1>
 </div>

 

 

Consola Web

La Consola Web viene configurada por defecto en Master, y está definido el acceso en el siguiente atributo del fichero de configuración de Master “ assetPublicURL: https://master.osc.test:8443/console/ “. Con la configuración de autenticación por defecto no podemos acceder via web, porque el API requiere de un token. Al haber configurado previamente la autenticación mediante HTTP, el usuario demo podrá acceder a la consola web.

En nuestro entorno de pruebas podemos, o bien en la máquina local, donde tengamos un navegador, seleccionamos gw.osc.test como DNS, o bien, será mi caso, configuraremos un proxy socks mediante una conexión ssh a mi máquina virtual.

Para no alterar demasiado la configuración del navegador, voy a hacer uso de un plugin originalmente creado para Firefox, pero disponible también para Chrome y otros, llamado Foxy Proxy. Este plugin permite configurar proxies y cambiar de uno a otro rápida y cómodamente. He instalado la versión Basic, y aquí dejo los enlaces de descarga para Firefox y Chrome. El proxy lo hago a la máquina Gateway con el comando ” ssh -D 1080 gw.osc.test

El primer acceso nos informará que no es seguro conectar, dado que nuestro master usa un certificado autofirmado. Simplemente aceptamos el certificado y nos logueamos con el usuario demo

Origin-v3-Web-Proyect

Veremos el proyecto que hemos creado. Pinchándo en él accedemos a los objetos del proyecto.

origin-v3-web-objects

Vemos un panel lateral que nos muestra acceso a:

  • Overview: Un vistazo general de todos los componentes dentro del proyecto
  • Browse: Desde aquí podemos acceder a las diferentes categorías de objetos, tales como servicios, pods, routers, etc.
  • Settings: ¿Necesita explicación? Los diferentes parámetros del proyecto,

Como el usuario demo es un usuario básico, sólo tiene acceso a sus proyectos y a administrar sus objetos, hay otras acciones que están restringidas. Las configuraciones de seguridad las veremos en otro post.

Nuestra aplicación sólo es accesible desde la red interna de los pods, por lo que sólo se puede acceder a ella desde alguno de los nodos de nuestro cluster. Podemos asignarle una IP externa, pero eso hace que tengamos que tener un a IP pública por cada aplicación, con reglas muy complejas. Master ha desplegado un POD especial router que se encarga de redirigir las peticiones que vayan con el subdominio configurado en la etiqueta “subdomain”  del fichero de configuración master-config.yaml. En nuestro caso se configuró el subdominio apps.osc.test.

Para poder tener acceso a nuestra aplicación vemos que en Overview hay un objeto SERVICE llamado ruby-hello-world, y a su derecha un enlace Create router, pincharemos en él.

origin-v3-web-route

Vemos que nos permite modificar algunos parámetros, tales como:

  • Name: El nombre del objeto route. Por defecto el nombre de la aplicación
  • Hostname: El hostname mediante el que accederemos a la aplicación. Es necesario un FQDN que el DNS resuelva con la dirección del Master. Si se deja en blanco tomará el valor <app-name>-<project-name>.<default-subdomain>, que en nuestro caso sería ruby-hello-world-test.apps.osc.test
  • Path: El contexto web de la aplicación
  • Target Port: La redirección de puerto del host hacia el pod

No modificamos nada y pinchamos en Create

Ahora vemos que en Overview el objeto SERVICE ha cambiado y nos aparece ahora el hostname de acceso a la aplicación

origin-v3-web-route-1

Si pinchamos en el hostname accederemos a la aplicación:

origin-v3-web-app

De acuerdo que sólo vemos eso, pero es que esa es la aplicación.

Algunos de los comandos más usados:

  • oc
    • get: Obtiene información básica
      • pods
      • nodes
      • routes
      • projects
      • endpoints
      • replicationcontrollers
      • deploymentconfigs
      • imagestreams
    • describe: obtiene información detallada
      • pods
      • nodes
      • routes
      • projects
      • endpoints
      • replicationcontrollers
      • deploymentconfigs
      • imagestreams
    • create: crea componentes
    • delete: elimina componentes

 

 

Y hasta aquí este post. En los siguientes posts veremos detalladamente los comandos para poder crear y gestionar nuestras aplicaciones aplicaciones, pero antes tendremos que ver como gestionar las políticas de seguridad de OpenShift. Nos vemos.

One thought on “OpenShift v3 (Mega Tutorial) – Parte 3 – CLI

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *