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
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
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> <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:
Veremos el proyecto que hemos creado. Pinchándo en él accedemos a los objetos del proyecto.
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.
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 en este momento el hostname de acceso a la aplicación:
Si pinchamos en el hostname accederemos a la aplicación:
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í el Mega Tutorial sobre OpenShift V3. Espero que haya quedado todo bastante claro, y si me queréis hacer alguna pregunta, no dudéis en contactarme a través de info@essiprojects
Nos vemos en otros blog post, donde me gustaría que viéramos más detalladamente los comandos para poder crear y gestionar nuestras aplicaciones aplicaciones y cómo gestionar las políticas de seguridad de OpenShift.
¡Hasta la próxima!
Essi Projects
Comparte la noticia
