Git Cookbook. Cambiar en nuestro repositorio local la rama del repositorio remoto que seguimos

Git

Para la elaboración de este artículo se ha utilizado la versión de git 2.7.4

Esta situación nos la encontramos cuando trabajamos con multiples repositorios remotos en nuestro repositorio local y en un momento determinado queremos dejar de seguir a la rama del repositorio remoto por defecto origin por otra rama de otro repositorio remoto diferente.

Para verlo con más claridad vamos a verlo con una secuencia de comandos.

Estado local de nuestro repositorio

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

Listado de los repositorios remotos

$ git remote -v
gitlab  ssh://... (fetch)
gitlab  ssh://... (push)
origin  ssh://... (fetch)
origin  ssh://... (push)

Cambiar el repositorio remoto por defecto al que seguimos

La opción -u es la misma que –set-upstream-to.

$ git branch -u gitlab/master
Branch master set up to track remote branch master from gitlab.

$ git status
On branch master
Your branch is up-to-date with 'gitlab/master'.
nothing to commit, working directory clean

A partir de este momento cada vez que hagamos cualquier operación con git donde interviene el repositorio, si no le indicamos nada, el repositorio por defecto donde se hace las operaciones es gitlab

Por ejemplo, cambiamos un fichero y hacemos un git push. Por defecto se va al repositorio remoto gitlab. Si no cambiamos el repositorio remoto por defecto al que seguimos, para enviar los cambios a origin tendriamos que hacer un git push origin master.

Vamos a seguir con la secuencia de comandos.

$ echo "Readme.md" > README.md
$ git add .
$ git commit -m "fichero readme"

# diferencia entre repositorio local y el remoto origin
#
$ git diff origin/master --name-only
README.md

# diferencia entre repositorio local y el remoto gitlab
#
$ git diff gitlab/master --name-only
README.md

# realizamos un push sin indicar el repositorio remoto. Los cambios van por defecto al repositorio *gitlab*
#
$ git push
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 299 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To ssh://...
   2c0999b..61dbe03  master -> master

# diferencia entre repositorio local y el remoto gitlab. En este caso no hay ninguna diferencia
#  
$ git diff gitlab/master --name-only

# diferencia entre repositorio local y el remoto origin. En este caso sigue existiendo el fichero modificado
#
$ git diff origin/master --name-only
README.md

# Subir los cambios al *origin* sin modificar el repositorio remoto que seguimos
#
$ git push origin master
Password authentication
Password:
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 299 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1)
remote: Updating references: 100% (1/1)
To ssh://...
   2c0999b..61dbe03  master -> master

# Ya no existe diferencia entre repositorio local y el remoto origin.
#
$ git diff origin/master --name-only

Creación de un cluster con docker swarm

Docker Logo

El artículo se ha escrito utilizando docker 1.12 y 4 máquinas ubuntu 16.04.1 LTS virtualizadas con VirtualBox, de las cuales solo 1 de ellas tenia instalado docker-machine.

Este artículo es una guia rápida de creación de un cluster de nodos de docker, gestionados de forma nativa por docker swarm.

Algunos de los conceptos manejados por docker swarm son:

  • nodos. Diferentes equipos ejecutando docker
  • manager. Uno de los nodos del cluster actúan de manager y es el responsable de gestionar los nodos del cluster.
  • worker. El resto de nodos son los workers. Estos con los responsables de ejecutar las tareas que el manager le indica, creando y ejecutando los contenedores. El manager también puede actuar como worker.

Cuando desplegamos una aplicación en un cluster de docker swarm, creamos una definición de un servicio. Esta definición del servicio la enviamos al manager. El manager divide el servicio en tareas o tasks y las envia a los workers, que son los que finalmente ejecutan las tareas. Estas tareas o tasks se traducen en la creación de los contenedores que son los que finalmente ejecutan nuestra aplicación.

Sigue leyendo

Aprovisionar o instalar docker en una máquina remota utilizando docker-machine

Docker Logo

Para la elaboración del artículo hemos utilizado docker 1.12 y dos equipos ubuntu 16.04.1 LTS virtualizados con Virtualbox

Guía rápida de aprovisionamiento de una máquina remota utilizando docker-machine y el driver genérico. Se trata por tanto de instalar de docker forma remota desde un equipo local.

Para el artículo vamos a suponer que

  • la máquina remota se llama remotehost
  • la cuenta del usuario del equipo remoto es udocker
  • la maquina local donde ejecutamos docker-machine es sourcehost

Sigue leyendo

Realizar un login remoto o ssh utilizando autenticación por certificado RSA

ssh

… o lo que es lo mismo realizar un login remoto o ssh sin utilizar usuario y contraeña.

Es el caso en el que queremos realizar un login remoto o login por ssh desde un equipo A a un equipo B (o a ‘n’ equipos) y no queremos utilizar el usuario y contraseña cada vez que realizamos el login.

Los pasos son los siguientes:

  • Relizar el login en el equipo A
  • Generar la clave rsa para autenticación
  • Copiar la clave rsa generada en el equipo B
  • Realizar el login en el equipo B utilizando la clave recién generada

Como podemos imaginarnos necesitamos tener cuentas en ambos equipos para poder realizar estos pasos

Generar las claves para autenticación desde el equipo A

El comando ssh-keygen genera las claves de autenticación que podemos utilizar para el protocolo ssh de versiones 1 y 2. En este caso dejamos en blanco la passphrase.

La cuenta de usuario en este equipo se corresponde con user1.

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user1/.ssh/id_rsa):
/home/user1/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user1/.ssh/id_rsa.
Your public key has been saved in /home/user1/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:a3xg5xjLeq8t7qYVwcaa/m4wK/K+zn/ugE5GTxW8WHE user1@equipoa
The key's randomart image is:
+---[RSA 2048]----+
...
...
+----[SHA256]-----+

Copiar la clave recién generada en el equipo B desde la cuenta de usuario del equipo A

La cuenta de usuario en el equipo B se corresponde con user2.

$ ssh-copy-id user2@equipob
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/user1/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
user2@equipob's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'user2@equipob'"
and check to make sure that only the key(s) you wanted were added.

Realizar el login ssh desde el equipo A en el equipo remoto B utilizando la clave recién copiada

$ ssh user2@equipob
Welcome to Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-31-generic x86_64)

A partir de ahora cada vez que realicemos el login en el equipo B no necesitaremos realizar el login ssh con la contraseña.

Spring Boot y el sistema de logging

Logo Spring

Resumen del funcionamiento del sistema de logging en Spring Boot 1.4.0.RELEASE

Principales características

  • Spring Boot utiliza internamente Commons Logging
  • Existe configuraciones para Java Util Logging, Log4J2 y Logback
  • Por defecto se utiliza la Consola para mostrar los logs. Opcionalmente podemos escribir en fichero
  • Logback es el sistema de log utilizado si utilizamos los Spring Boot Starters (spring-boot-starter-parent, etc)
  • Logback tiene niveles ERROR, WARN, INFO, DEBUG o TRACE pero no tiene FATAL
  • Se permite extender el comportamiento de logback mediante extensiones
  • Por defecto se muestran los niveles ERROR, WARN e INFO

Activación del nivel DEBUG

Como cualquier aplicación de Spring Boot podemos activar el nivel de DEBUG como cualquier configuración más. Eso significa que podemos indicarselo como argumento al arrancar la aplicación, como variable de entorno, en el application.properties o application.yml, etc

Es importante mencionar que la activacion del nivel de DEBUG solo afecta internamente a Spring Boot, no a los logs de nuestra aplicación, los cuales los tenemos que configurar mediante otro mecanismo.

Por ejemplo,

En el arranque de la aplicación

$ java -jar my-application.jar --debug

En el fichero application.properties o application.yml

...
debug=true
...
debug: true

Escribir logs a fichero

Por defecto Spring Boot escribe por consola pero opcionalmente le podemos decir que escriba a fichero.

Al igual que la activación del nivel a DEBUG la configuración para activar el fichero de log sigue el mismo principo de configuración de Spring Boot.

Los ficheros rotan por defecto cada 10Mb.

Las propiedades para indicar el fichero donde escribir los logs son:

  • logging.file
  • logging.path

Modificar los niveles de logs de nuestra aplicación o de librerías de terceros

Siguiendo los mismos principios de configuración de Spring Boot la modificación de los nieves de log de nuestra aplicación o de librerías de terceros es bastante fácil.

Por ejemplo,

En el arranque de la aplicación

java -jar my-application.jar --logging.level.org.myapp=DEBUG

En el fichero de configuración application.properties o application.yml

logging.level.org.myapp=DEBUG
...
logging:
   level:
     org:
       myapp: DEBUG

Activar otros sistemas de log

Se acivan por defecto al incluirlos en el classpath.

Podemos forzar a Spring Boot a utilzar un sistema de logging diferente al por defecto, configurando la propiedad de sistema:

org.springframework.boot.logging.LoggingSystem=Nombre completo de la clase que implementa el sistema de logging

o bien desactivar por completo el sistema de logging

org.springframework.boot.logging.LoggingSystem=none

Configuración de estos sistemas de logging

Una vez hemos cambiado el sistema de logging, Spring Boot se encargaría de leer lo ficheros de configuración de esos sistemas, aunque se recomienda que se utilicen la versión para Spring Boot.

Es decir, para los sistemas de logging como

  • log4j2 el fichero de configuración es log4j2.xml
  • Para Java Util Logging el fichero de configuración es logging.properties

pero Spring boot recomienda que utilicemos la versión para Spring Boot que serían respectivamente:

  • log4j2-spring.xml
  • logging-spring.properties

Docker cookbook. Subir una imagen a nuestro Docker Registry privado

Docker Logo

La versión de docker utilizada para ejecutar los comandos de este artículo ha sido docker 1.12.0 en un sistema Ubuntu 16.04.1 LTS

Cuando empezamos a trabajar con Docker una de las primeras cosas que utilizaremos es el Docker Resgitry proporcionado por la gente de Docker y publicado en Docker Hub.

Como sabemos es la imagen utilizada para crear un contenedor donde subiremos nuestras imágenes de nuestros proyectos de forma privada. Eso si, con algunas limitaciones en cuanto a seguridad etc.

Como toda imagen subida a Docker Hub podemos disponer de ella y arrancar nuestro contenedor con un simple comando:

$ docker run -d -p 5000:5000 --name registry registry:2

Los pasos a seguir una vez tenemos nuestra imagen son muy sencillos. Basta con etiquetarla indicando el host del Docker Registry donde tiene que subir:

$ docker tag 5f7ca7e96e33 my-registry:5000/my-image:0.0.1-SNAPSHOT
$ docker push my-registry:5000/my-image:0.0.1-SNAPSHOT
The push refers to a repository [my-registry.com:5000/my-image]
Get https://my-registry.com:5000/v1/_ping:http: server gave HTTP response to HTTPS client

En este momento es cuando nos encontramos con la primera limitación de este Registry. No soporta la seguridad por SSL, y por lo tanto debemos decir a nuestro docker daemon que debe poder comunicarse con my-registry.com de forma no segura.

La configuración que debemos hacer es muy sencilla. Indicar el host de nuestro Registry, reiniciar el daemon y volver a subir la imagen

$ echo '{ "insecure-registries":["my-registry.com:5000"] }' > /etc/docker/daemon.json
$ sudo systemctl restart docker
$ docker push  my-registry.com:5000/my-image:0.0.1-SNAPSHOT
The push refers to a repository [my-registry.com:5000/my-image]
0d84ae38f138: Pushed
c18156f94ccc: Pushed
...
...
0.0.1-SNAPSHOT: digest: sha256:fceb6ceb9277761036ec670c1e23f30a3667441f98c54b4253c94737abb0b418 size: 4482

Montar un entorno con Zookeeper, Kafka y Yahoo Kafka Manager utilizando Docker

Docker Logo

Construir la imagen de “kafka manager docker” para kafka 0.9

Los pasos son los siguiente:

Clonar el repositorio

git clone https://github.com/DockerKafka/kafka-manager-docker.git

Crear un nuevo branch a partir del tag 1.2.7

git checkout -b 1.2.7.mylocal 1.2.7

Modificar el Dockerfile para utilizar los fuentes de Yahoo Kafka Manager con soporte a Kafka 0.9

Editamos el fichero Dockerfile y modificamos

KM_VERSION=1.2.7

por

KM_VERSION=1.3.1.6

Construimos la imagen

docker build -t my-kafka-manager .

Levantar Zookeeper, Kafka y Kafka Manager

docker run -d --name kafkadocker_zookeeper_1  dockerkafka/zookeeper
docker run -d --name kafkadocker_kafka_1 --link kafkadocker_zookeeper_1:zookeeper dockerkafka/kafka
docker run -it --rm --link kafkadocker_zookeeper_1:zookeeper --link kafkadocker_kafka_1:kafka -p 9000:9000 -e ZK_HOSTS=zookeeper:2181 my-kafka-manager

Acceder a Kafka Manager y dar de alta los cluster que queremos gestionar

Accedemos a la interface web en http://host:9000 y damos de alta el cluster que queremos gestionar.

Para ello debemos saber el host y puerto del Zookeeper que estamso utilizando. Si nos hemos fijado en los pasos anteriores el zookeeper es:

Host:puerto = zookeeper:2181

Yahoo Kafka Manager

Urls