Open-Source | Luis Cacho

Differences between Kubernetes and Openshift

Thu, 25 Mar 2021 09:10:47 -0500

Differences between Kubernetes and Openshift

Luis Cacho

Senior Container Infrastructure Consultant

@Red Hat

Kubernetes

Some assembly required

Kubernetes

Some assembly required

Kubernetes

Some assembly required

Openshift

Value Added

Openshift

Value Added

Openshift

Value Added

Openshift contains Kubernetes

Conclusion

Openshit IS a Kubernetes flavor

Thank You

Differences between Kubernetes and Openshift

Thu, 25 Mar 2021 09:09:11 -0500

Personal Website

Sun, 24 Nov 2019 00:00:00 +0000

Static site for luiscachog.io using:

Actual status:

Kubernetes Contributor

Sun, 27 Oct 2019 00:00:00 +0000

Contributing to the Kubernetes project in different special interest groups, mainly focused on migration and modernization, documentation, community, and user/contributor experience.

Prow PR Dashboard

sig-docs

Contributor on the Spanish translation content at kubernetes.io in sig-docs.

kubernetes-docs-es

konveyor

Ansible Galaxy Roles

Fri, 25 Oct 2019 00:00:00 +0000

CircleCI Role: Ansible role that installs CircleCI CLI on your server/workstation.
Sonobuoy Role: Ansible role that installs sonobuoy on your server/workstation.

Molecule Cookiecutter

Thu, 24 Oct 2019 00:00:00 +0000

A Cookiecutter template for your new Molecule project.

Docker Login the Right Way

Wed, 15 May 2019 00:00:00 +0000

Table of Contents

Hi again!

It is been a while since I wrote something here, as always, there is no much time for a hobby.

I’ve been working for a while with docker, not a production level, but for some applications that I use at work. And since the Docker Hub Data breach I put more atention on the security of my data/credentials, so I investigate a little about and found this official repository https://github.com/docker/docker-credential-helpers/ from Docker where are the supported credential helpers.

Credential Store

Docker keeps our credentials saved on a JSON file located on ~/.docker/config.json, but unfortunatelly credentials are just encrypted on base64, here is an articule/video where there is an explanation for the why it is a bad idea to just use base64 encryption.

The following is a diagram on how a plain text storage works:

Plain Text Storage

Here is an example on how ~/.docker/config.json looks like when is using plain text credentials:

cat ~/.docker/config.json
{
 "auths": {
 "https://index.docker.io/v1/": {
 "auth": "azRjaDA6c3VwZXJzZWNyZXRwYXNzd29yZAo="
 },
 "quay.io": {
 "auth": "azRjaDA6c3VwZXJzZWNyZXRwYXNzd29yZAo="
 }
 },
 "HttpHeaders": {
 "User-Agent": "Docker-Client/18.09.6 (linux)"
 }
}

After a successful docker login command, Docker stores a base64 encoded string from the concatenation of the username, a colon, and the password and associates this string to the registry the user is logging into:

$ echo azRjaDA6c3VwZXJzZWNyZXRwYXNzd29yZAo= | base64 -d -
luiscachog:supersecretpassword

A docker logout command removes the entry from the JSON file for the given registry:

$ docker logout quay.io
Remove login credentials for quay.io

$ cat ~/.docker/config.json
{
 "auths": {
 "https://index.docker.io/v1/": {
 "auth": "azRjaDA6c3VwZXJzZWNyZXRwYXNzd29yZAo="
 }
 },
 "HttpHeaders": {
 "User-Agent": "Docker-Client/18.09.6 (linux)"
 }
}

Docker Credential Helpers

Since docker version 1.11 implements support from an external credential store for registry authentication. That means we can use a native keychain of the OS. Using an external store is more secure than storing on a “plain text” Docker configuration file.

Secure Storage

In order to use a external credential store, we need a program to interact with.

The actual list of “official” Docker Credential Helper is:

docker-credential-osxkeychain: Provides a helper to use the OS X keychain as credentials store.
docker-credential-secretservice: Provides a helper to use the D-Bus secret service as credentials store.
docker-credential-wincred: Provides a helper to use Windows credentials manager as store.
docker-credential-pass: Provides a helper to use pass as credentials store.

docker-credential-secret service

On this post we will explore the docker-credential-secretservice and how to configure it.

We need to download and install the helper. You can find the lastest release on https://github.com/docker/docker-credential-helpers/releases. Download it, extract it and make it executable.

wget https://github.com/docker/docker-credential-helpers/releases/download/v0.6.2/docker-credential-secretservice-v0.6.2-amd64.tar.gz
tar -xf docker-credential-secretservice-v0.6.2-amd64.tar.gz
chmod +x docker-credential-secretservice
sudo mv docker-credential-secretservice /usr/local/bin/

Then, we need to specify the credential store in the file ~/.docker/config.json to tell docker to use it. The value must be the one after the prefix docker-credential-. In this case:
```
{
 "credsStore": "secretservice"
}
```
To facilite the configuration and do not make mistakes, you can run:
```
sed -i '0,/{/s/{/{\n\t"credsStore": "secretservice",/' ~/.docker/config.json
```

From now we are uning an external store, so if you are currently logged in, you must run docker logout to remove the credentials from the file and run docker login tostart using the new ones.

Let me know how this works for you.

References:

Docker Credential Helpers repository¹
Docker Credential Store Documentation²
Slides about this topic ³

Bulk Delete Rackspace Cloud Files data via API

Wed, 13 Feb 2019 00:00:00 +0000

Sometimes it is necessary to delete all the content of the Cloud Files containers, however, the API does not have a proper method to delete the data and the containers on the same API call. Also, accoring to the documentation, you can only delete empty containers.

So, in cases where you need to delete the data and the containers at the same time, you should follow the next steps:

Download Turbolift, I know it is an old tool.

git clone https://github.com/cloudnull/turbolift
cd turbolift

In order to get and isolated installation, we are going to create a Python Virtual Environment (virtualenv)
```
mkvirtualenv turbolift
workon turbolift
```
Install the tool
```
pip install turbolift
```

Now, prior to start to play with the API calls, we need to grab some data to authenticate with the API:

Variable	Definition
USERNAME	This is the Rackspace Public Cloud username
APIKEY	This is your API-KEY
REGION	This is the Region where the Cloud Files are located (dfw, ord, iad, lon, hkg)
TOKEN	The TOKEN is generated after you get authenticated
ENDPOINT	This ENDPOINT is given also after you get authenticated

Next step, we are going to use cURL, to perform all the API calls:

First of all, get the TOKEN:

USERNAME=YOUR-USERNAME
APIKEY=YOUR-APIKEY
TOKEN=$(curl -s -XPOST https://identity.api.rackspacecloud.com/v2.0/tokens \
 -d'{"auth":{"RAX-KSKEY:apiKeyCredentials":{"username":"'$USERNAME'","apiKey":"'$APIKEY'"}}}' \
 -H"Content-type:application/json" | jq '.access.token.id' | tr -d "\"")

Next step, get the ENDPOINT:

ENDPOINT=$(curl -s -XPOST https://identity.api.rackspacecloud.com/v2.0/tokens \
 -d'{"auth":{"RAX-KSKEY:apiKeyCredentials":{"username":"'$CL_USERNAME'","apiKey":"'$APIKEY'"}}}' \
 -H"Content-type:application/json" | jq '.access.serviceCatalog[] | select((.name=="cloudFiles") or (.name=="cloudFilesCDN")) | {name} + .
 endpoints[] | .publicURL' | tr -d "\"" | grep -v cdn | grep -i $REGION)

In this case we are skipping all te CDN endpoints, but you can add them if is necessary.

With all the collected data, next step is use turbolift to delete the Cloud Files container and their data. To do it, I use a for-loop:

for i in $(curl -s -H "X-Auth-Token: $TOKEN" $ENDPOINT); do turbolift -u $USERNAME -a $APIKEY --os-rax-auth $REGION delete -c $i ; done

Now, you have all the Data and Cloud Files containers deleted on one region.

😄

My First Contribution to OpenStack project

Thu, 15 Mar 2018 00:00:00 +0000

I been working since last year using Ansible for fun and to trying to get prepared to become a DevOps, so I found an excelent OpenStack project called ARA Records Ansible.

Ansible Logo

ARA Logo

Basically it is a project from the OpenStack community that makes it easier to understand and troubleshoot your Ansible roles and playbooks. If you want more information, please refer to the Documentation Page.

Anyhow, I just found a little bug on the Ansible Role to install ARA ansible-role-ara on Debian based distros and just send the patch to fix it.

Here is the link to my contribution.

And, as I am proud of my first commit on a big project here is the screenshot too:

My First OpenStack Contribution

I feel happy and motivated to still learn about this Open-Source project and a lot more.

😄

Deployment de un sitio estatico con Hugo y Git Hooks

Mon, 05 Mar 2018 00:00:00 +0000

Table of Contents

Motivación

Estoy intentando escribir un poco más en mi blog, ya que noté que muchas veces no lo hacia muy a menudo por que al llegar a la consola de administración de Wordpress, habia que dar bastantes clicks para llegar al menu de “Posts”, además de que cada vez que entraba había un plugin diferente que actualizar, y verificar que nada se rompiera con las nuevas actualizaciónes, en pocas palabras hay que darle bastante mantenimiento a un sitio con Wordpress, y además de eso había que dedicarse a escribir el post.

Otra razón por lo que opté hacer el cambio de plataforma, es que al estar tratando de convertirme en DevOps, es necesario, desde mi punto de vista; tratar automatizar/scriptear la mayoria de tus tareas que realizas día a día, y con Hugo considero que se puede realizar este objetivo también.

Consideraciones

Una vez que decidí migrarme de Wordpress, el siguiente paso era decidir a que plataforma mudarme. De entrada la plataforma que queria probar era un Static Site Generator, aqui otro link de por que usar un Static Site Generator.

Partiendo de lo anterior, las opciones que me parecieron interesantes fueron:

Cada una de las opciones tiene diferentes caracteristicas, que no vamos a discutir en este post, sin embargo las carteristicas que me convencieron de usar Hugo por encima de las otras alternativas fueron:

Consta solamente de un binario, que comparado con las otras posibilidades hay que instalar todo un ambiente de desarrollo/producción.
Es bastante rápido.
Es Multi-plataforma
Tiene diversos temas

Instruciones

Consideraciones técnicas

El ambiente consta de:

1 servidor productivo donde esta instalado hugo, git y un servidor web (apache o nginx) , haremos todos los deployments usando el usuario admin, ojo que no es el usuario root.
1 servidor/equipo de desarrollo, de igual forma que cuenta con hugo y git, en mi caso, es mi computadora personal y mi usuario es luiscachog.
1 cuenta de github.com

Autenticación mediante llaves SSH

El primer paso es realizar el intercambio de llaves SSH entre el equipo de desarrollo y el equipo productivo. Para ello seguimos los siguientes pasos:

Generar la llave SSH, tendrás que contestar algunas preguntas, entre las cuales está si quieres ponerle un password, a lo cual deberas dejarlo en blanco para que no te pida contraseña.
```
luiscachog@dev-server:~$ ssh-keygen
```

Copiar la llave SSH hacia el equipo productivo:

luiscachog@dev-server:~$ ssh-copy-id admin@IP_servidor_productivo

Verificar que te puedas conectar desde tu servidor de desarrollo, con tu usuario al servidor productivo, con el usuario que realizará los deployments.
```
luiscachog@dev-server:~$ ssh admin@162.125.2.30 hostname
```
En este caso, debera de mostrarte el hostname del servidor productivo sin pedirte el password.

Configuración sitio con Hugo

El siguiente paso es configurar nuestro ambiente de desarrollo con Hugo y Git.

Para instalar ambos en Ubuntu o derivados debes de ejecutar:
```
luiscachog@dev-server:~$ sudo apt install hugo git
```
Para tener la version más actualizada de hugo puedes seguir los pasos descritos en este link

Vamos a crear un directorio de trabajo para nuestro sitio estatico

luiscachog@dev-server:~$ mkdir ~/sites
luiscachog@dev-server:~$ cd ~/sites

Crearemos un nuevo sitio usando el comando hugo

luiscachog@dev-server:~$ hugo new site luiscachog.io
Congratulations! Your new Hugo site is created in /home/luiscachog/sites/luiscachog.io.

Just a few more steps and you're ready to go:

1.- Download a theme into the same-named folder.
 Choose a theme from https://themes.gohugo.io/, or
 create your own with the "hugo new theme <THEMENAME>" command.
2.- Perhaps you want to add some content. You can add single files
 with "hugo new <SECTIONNAME>/<FILENAME>.<FORMAT>".
3.- Start the built-in live server via "hugo server".

Visit https://gohugo.io/ for quickstart guide and full documentation.

Cuando termine de correr el comando se podra apreciar los siguientes directorios y archivos

luiscachog@dev-server:~$ cd luiscachog.io
luiscachog@dev-server:~$ ls
archetypes config.toml content data layouts static themes
luiscachog@dev-server:~$ tree
.
├── archetypes
│   └── default.md
├── config.toml
├── content
├── data
├── layouts
├── static
└── themes

6 directories, 2 files

El siguiente paso es agregar un tema, puedes encontrar uno que te guste en https://themes.gohugo.io/
```
git init
git submodule add https://github.com/budparr/gohugo-theme-ananke.git themes/ananke

# Edit your config.toml configuration file
# and add the new theme.

echo 'theme = "ananke"' >> config.toml
```
Como recomendación adicional en este paso, puedes realizar un fork del tema que te guste en github para poder realizar modificaciones y proponer cambios al mismo, contribuyendo de esa forma a su desarrollo, para hacerlo, sigue los pasos:
1. Realizar un fork del tema, sigue esta guia para hacerlo.
2. Al realizar el fork, tendras en tus repositorios de github el tema que quieras, por lo que tendras que ejecutar los mismos comandos del punto anterior, pero el repositorio del tema apuntara a tu usario en github
```
git init
git submodule add https://github.com/luiscachog/gohugo-theme-ananke.git themes/ananke
# Edit your config.toml configuration file
# and add the new theme.

echo 'theme = "ananke"' >> config.toml
```
Vamos a crear un post de prueba para verificar que todo esta funcionando correctamente
```
hugo new posts/my-first-post.md
echo "Hola Mundo" >> content/posts/my-first-post.md
```
El comando anterior creara un archivo en la ruta content/posts/my-first-post.md, y el contenido será:
```
---
title: "My First Post"
date: 2018-02-28T12:02:38-06:00
draft: true
---
Hola Mundo!!!
```
Finalmente, probaremos que nuestro sitio estatico con nuestro post se muestren de manera local, en nuestro servidor de desarrollo. Cabe mencionar, que por defecto el comando ‘hugo server’ no mostrará los posts que tengan la opción ‘draft: true’, por ello se agrega la bandera -D
```
luiscachog@dev-server:~$ hugo server -D
```

Configuración del repositorio Git en el servidor de desarrollo 1ra parte

En el paso pasado, realizamos la inicialización del repositorio dentro del directorio del sitio estatico:

luiscachog@dev-server:~$ pwd
/home/luiscachog/sites/luiscachog.io
luiscachog@dev-server:~$ git status
On branch master

Initial commit

Changes to be committed:
 (use "git rm --cached <file>..." to unstage)

 new file: .gitmodules
 new file: themes/ananke

Untracked files:
 (use "git add <file>..." to include in what will be committed)

 archetypes/
 config.toml
 content/
 themes/ananke/

Ahora, para tener el repositorio publico, tenemos que crear el repositorio en github.com y configurarlo como un repositorio remoto

luiscachog@dev-server:~$ git add *
luiscachog@dev-server:~$ git commit -m "First commit"
luiscachog@dev-server:~$ git remote add origin https://github.com/luiscachog/luiscachog.io
luiscachog@dev-server:~$ git push -u origin master

Configuración del repositorio Git en el servidor productivo

Para poder ocupar los hooks de git es necesario hacer una primera copia inicial del repositorio en el que vamos a trabajar, con la particularidad de que el repositorio clonado debe ser del tipo bare.

En nuestro servidor productivo haremos:

admin@prod-server:~$ mkdir sites
admin@prod-server:~$ cd sites
admin@prod-server:~$ git clone --bare https://github.com/luiscachog/luiscachog.io luiscachog.io.git

Configuración del hook

Ya que tenemos nuestro repositorio tipo bare en el servidor productivo vamos a crear el script que mandará a llamar el hook de git.
```
admin@prod-server:~$ cd sites/luiscachog.io.git/hooks
admin@prod-server:~$ vim post-update
```

Y agregamos algo asi:

#!/bin/bash

GIT_REPO=$HOME/luiscachog.io.git
WORKING_DIRECTORY=/var/www/vhosts/luiscachog.io/working_hugo
PUBLIC_WWW=/var/www/vhosts/luiscachog.io/public_html
BACKUP_WWW=/var/www/vhosts/luiscachog.io/backup_html
MY_DOMAIN=luiscachog.io

set -e

rm -rf $WORKING_DIRECTORY
rsync -aqz $PUBLIC_WWW/ $BACKUP_WWW
trap "echo 'A problem occurred. Reverting to backup.'; rsync -aqz --del $BACKUP_WWW/ $PUBLIC_WWW; rm -rf $WORKING_DIRECTORY" EXIT

git clone $GIT_REPO $WORKING_DIRECTORY
mkdir -p $WORKING_DIRECTORY/themes
rm -rf $PUBLIC_WWW/*
/home/admin/bin/hugo -v -s $WORKING_DIRECTORY -d $PUBLIC_WWW -b "http://${MY_DOMAIN}"
trap - EXIT

Damos permisos de ejecución al script

admin@prod-server:~$ chmod +x post-update

Probamos que nuestro script funcione adecuadamente:

admin@prod-server:~$ ~/sites/luiscachog.io.git/hooks/post-update

Cloning into '/var/www/vhosts/luiscachog.io/working_hugo'...
done.
0 draft content
0 future content
4 pages created
0 paginator pages created
0 tags created
1 categories created
in 26 ms

Podras verificar tu nuevo post en la URL de su sitio:
```
http://production_domain_or_IP
```

Configuración del repositorio Git en el servidor de desarrollo 2da parte

Una vez tenemos configurado nuestro repositorio en el servidor de producción, procedemos a agregarlo como repositorio remoto en nuestro servidor de desarrollo

luiscachog@dev-server:~$ cd /home/luiscachog/sites/luiscachog.io
luiscachog@dev-server:~$ git remote add prod admin@IP_servidor_productivo:luiscachog.io
luiscachog@dev-server:~$ git ls-remote prod
d1b0b73528ab3117170ef74e133d0194dd2bc88a HEAD
d1b0b73528ab3117170ef74e133d0194dd2bc88a refs/heads/master

Puedes verificar los repositorios remotos con el comando:

luiscachog@dev-server:~$ git remote -v
origin git@github.com:luiscachog/luiscachog.io.git (fetch)
origin git@github.com:luiscachog/luiscachog.io.git (push)
prod admin@IP_servidor_productivo:luiscachog.io.git (fetch)
prod admin@IP_servidor_productivo:luiscachog.io.git (push)

Ahora cada vez que realizemos un push hacia el remote llamado ‘prod’ se llamara la función del hook.

luiscachog@dev-server:~$ cd /home/luiscachog/sites/luiscachog.io
luiscachog@dev-server:~$ hugo new posts/Testing-Deployment.md
luiscachog@dev-server:~$ echo "Deployment Test" >> content/posts/Testing-Deployment.md
luiscachog@dev-server:~$ git add *
luiscachog@dev-server:~$ git commit -m 'Deployment test with git hooks'

Este es el comando que hace la magia:

luiscachog@dev-server:~$ git push prod master
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 310 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Cloning into '/var/www/vhosts/luiscachog.io/working_hugo'...
remote: done.
remote: Cloning into '/var/www/vhosts/luiscachog.io/working_hugo/themes/hugo-future-imperfect'...
remote: INFO 2018/03/01 03:12:34 Using config file: /var/www/vhosts/luiscachog.io/working_hugo/config.toml
remote: Building sites … INFO 2018/03/01 03:12:34 syncing static files to /var/www/vhosts/luiscachog.io/public_html/
remote:
remote: | EN
remote: +------------------+----+
remote: Pages | 10
remote: Paginator pages | 0
remote: Non-page files | 0
remote: Static files | 3
remote: Processed images | 0
remote: Aliases | 1
remote: Sitemaps | 1
remote: Cleaned | 0
remote:
remote: Total in 44 ms
To admin@IP_servidor_productivo:luiscachog.io.git
 d5b0671..cvc4dee master -> master

Listo ya podemos probar nuestro sitio

http://luiscachog.io

Con esto el siguiente paso que realizare es hacer el deployment de mi servidor para el blog usando Ansible.

Nos Vemos!!!

References: Digital Ocean blog post ¹

Digital Ocean ↩︎

Open-Source | Luis Cacho

Differences between Kubernetes and Openshift

Differences between Kubernetes and Openshift

Luis Cacho

Senior Container Infrastructure Consultant

@Red Hat

Kubernetes

Some assembly required

Kubernetes

Some assembly required

Kubernetes

Some assembly required

Openshift

Value Added

Openshift

Value Added

Openshift

Value Added

Openshift contains Kubernetes

Openshift contains Kubernetes

Conclusion

Openshit IS a Kubernetes flavor

Thank You

Differences between Kubernetes and Openshift

Personal Website

Kubernetes Contributor

sig-docs

kubernetes-docs-es

konveyor

Ansible Galaxy Roles

Molecule Cookiecutter

Docker Login the Right Way

Docker Login the right Way

Credential Store

Docker Credential Helpers

docker-credential-secret service

Bulk Delete Rackspace Cloud Files data via API

My First Contribution to OpenStack project

Deployment de un sitio estatico con Hugo y Git Hooks

Motivación

Consideraciones

Instruciones

Consideraciones técnicas

Autenticación mediante llaves SSH

Configuración sitio con Hugo

Configuración del repositorio Git en el servidor de desarrollo 1ra parte

Configuración del repositorio Git en el servidor productivo

Configuración del hook

Configuración del repositorio Git en el servidor de desarrollo 2da parte