Saltar al contenido

Linux

Publicación APIs

  • admin 

Publicación APIs

He estado revisando un poco el tema de cómo hacen los grandes para publicar sus APIs, y por lo que veo no hay una regla más o menos común.

Por lo que parece cada uno tiene su método para publicar sus APIs públicas en la web de una forma más o menos automatizada, de tal forma, que se genera un contenido estático que se puede consultar como referencia, supongo que bien a partir de unos ficheros de definición del API, o a partir del propio código.

Por ejemplo, uno de los APIs más extensamente documentados es el API REST de cloudfare:

  • API REST CLOUDFARE

https://api.cloudflare.com/

Todo el API viene documentado con ejemplos de solicitudes y respuestas, y las solicitudes vienen agrupadas por categorías. Lo que veo también es que las APIs van mutando conforme a sus necesidades, por lo que el servidor de APIs suele mantener las URLs antiguas, y las solicitudes se realizan siempre sobre una URL que dentro del árbol contiene la versión del API.

En el caso de cloudfare se ve que el proceso de publicación, si bien es automatizado, contiene texto explicativo para cada llamada así como ejemplos, lo que lleva a suponer que igual se genera automáticamente a partir de la documentación contenida dentro del propio código que la soporta.

  • API KUBERNETES

Otro de los ejemplos de APIs REST extensamente documentados en la web es el API de Kubernetes:

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.9/

La documentación de este API, como su propio nombre dice en la URL, está «generado». Escarbando un poco más vemos que utiliza el swagger para definir y documentar las APIs:

https://kubernetes.io/docs/concepts/overview/kubernetes-api/

Según comenta en el link de arriba, las APIs son documentadas y expuestas directamente a través del servidor de APIs utilizando los documentos de especificación openAPI con el swagger. Se da la circunstancia de que kubernetes facilita herramientas al administrador del sistema que permiten generar y modificar APIs adhoc para gestionar su plataforma de contenedores a medida. Dichas APIs se generan por linea de comando y almacenan de forma serializada en el servidor de APIs para poder ser publicadas y expuestas por el servidor conforme se van generando y/o modificando. Hay otro link en un foro que habla sobre el tema aquí:

https://thenewstack.io/taking-kubernetes-api-spin/

  • APIS GENERADAS SOLUCION SPRING BOOT

En otro link se comenta una solución para publicar en base a los ficheros openAPI las APIs generadas para una solución de software llamada spring boot:

https://keyholesoftware.com/2017/03/28/auto-publishing-monitoring-apis-with-spring-boot/

Como curiosidad, el propio kubernetes utiliza un API alternativo basado en el protocol buffers desarrollado por google, y que utilizan extensivamente las plataformas de microservicios desplegadas bajo demanda en la nube. Aquí aparece la justificación de la migración del API al nuevo formato, por motivos de escalabilidad y simplicidad, principalmente.

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md

En el caso de Go se utiliza una librería llamada gogo-protobuff mucho más eficiente a efectos de rendimiento en la serialización/deserialización que la librería nativa de google. Esta es la página del proyecto donde aparecen también algunas de las empresas que la usan, entre ellas Cloudfare:

https://github.com/gogo/protobuf

Como veis el tema de la optimización y gestión de APIs es un problema recurrente.

  • DOCUMENTACION APIS POR GOOGLE

Este es el enfoque utilizado por Google para su API de gestión de cloud:

https://cloud.google.com/apis/design/proto3

https://developers.google.com/protocol-buffers/

Aquí tienen publicada en github las APIs, en un repositorio:

https://github.com/googleapis/googleapis

Los ficheros de entrada son los protobuff, y también ficheros YAML. Con esos ficheros utilizan una herramienta llamada Artman para generar y publicar las APIs:

https://github.com/googleapis/artman

Al generar y publicar las modificaciones de las APIs automáticamente mediante el repositorio GIT, utilizan una sistema de integración continua (en este caso en lugar de Travis utilizan Circle) para ver los resultados de las pruebas:

https://circleci.com/gh/googleapis/googleapis

Pues eso, que cada maestrillo tiene su librillo, pero la cosa se resume en que se utiliza un lenguaje para especificar los mensajes petición/respuesta del API, y este se compila tanto para generar las funciones de serialización/deserialización de los mensajes, como para publicarlo y hacerle las pruebas de regresión, etc… con el fin de que un cambio en la especificación no rompa nada en los servicios que están en producción. La apuesta de Google por la cosa esta es que tiene unos 48000 y pico mensajes en más de 12000 APIs para gestionar todos sus servicios internos, y mantener y escalar todo eso se convertía en un infierno, por eso hace unos 5 años empezaron a apostar por el proyecto y a migrar todo internamente al nuevo formato de encapsulación de datos. En este link aparece un poco de historia y explica bastante bien los motivos que les condujeron a adoptar esa solución:

https://developers.google.com/protocol-buffers/docs/overview

Como podéis ver la generación de los ficheros proto para los mensajes es bastante sencilla, y eso es precisamente lo que andaba buscando la gente de Google, enfocarse en la parte de la lógica del microservicio y dejar a la capa de transporte en un plano aparte con un problema resuelto.

Aplicado al caso práctico con el swagger: supongo que si el kubernetes tiene la posibilidad de publicar en el servidor de APIs los ficheros openAPI generados usando el swagger, debe de haber alguna forma de mantener en un repositorio git los ficheros YAML o JSON con las especificaciones openAPI, y en el swagger configurar el directorio con la versión actualizada de los ficheros del repo para poder publicarlo directamente a través del puerto.

Es decir, que haces un commit sobre el repositorio git, y se lanza un webhook (o periódicamente por crontab) un proceso para clonar la ultima versión de las APIs sobre el directorio del que se alimenta el swagger para publicar las APIs. El tema de probar las APIs ya es cosa de hacerlo en un servidor de integración continua sobre un entorno de pruebas y publicar los resultados.

Clustering Mysql con Vitess

  • admin 

Clustering Mysql con Vitess

Viendo algunos de los proyectos con Golang que utilizan en Google, este me ha llamado la atención, porque es lo que utilizan desde 2011 con Youtube para mantener la BBDD de Mysql en cluster:

http://vitess.io/

https://github.com/youtube/vitess/

Entre sus funcionalidades, no solo mantiene el tema de la replicación y el shardening entre los nodos (en Youtube son decenas de miles de nodos con MySQL), sino que optimiza las operaciones que pueden sobrecargar la BBDD así como el uso de la caché, la gestión de los backups, etc…

Mirmon monitoriza repositorios replicados

Mirmon monitoriza repositorios replicados

Hay una herramienta opensource para la monitorización de los repositorios replicados (mirrors) de forma distribuida. Se llama mirmon:

http://www.staff.science.uu.nl/~penni101/mirmon/

La cosa es que tiene un uso bastante extendido en los proyectos opensource populares. Aquí tenenos un ejemplo de los mirrors del XBMC:

http://mirrors.xbmc.org/mirmon.html

Para los repositorios CPAN:

http://mirrors.cpan.org/

No está mal la herramienta.

Guía uso Iperf

  • admin 

Guía Uso Iperf

Iperf es una herramienta muy útil para comprobar el ancho de banda real de conexión disponible. Tanto para Unix y/o Windows.

Iperf puede configurarse en 2 modos:

  • Modo Servidor
  • Modo Cliente.

El host en modo iperf servidor escucha conexiones remotas originadas desde potenciales host iperf cliente. El host iperf cliente define los parámetros de test de ancho de banda, y se conecta al servidor remoto.

 

  • Instalación iperf.

apt-get install iperf

 

  • Iniciar servidor iperf.

iperf -s

root@smokeping1:/# iperf -s
————————————————————
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
————————————————————

 

  • Arrancar servidor iperf como demonio.

Se puede arrancar el servidor manual, o como demonio. Para este segundo caso se debe añadir el parámetro -D (se ejecuta iperf como demonio en background).

iperf -s -D

iperf -s -D > /var/log/iperf-log.log

root@server:/home/ubuntu# iperf -s -D > /var/log/iperf-log.log
Running Iperf Server as a daemon
The Iperf daemon process ID : 3546
root@server:/home/ubuntu#

  • Conectar un host iperf client a un host iperf servidor

Iperfs necesita ejecutarse en el host local en modo cliente, así como en el servidor remoto en modo servidor. Se debe explicitar la ip con el argument -c.

iperf -c ip_servidor.

[root@fc18-atica ~]# iperf -c 112.131.5.76
————————————————————
Client connecting to 212.231.5.76, TCP port 5001
TCP window size: 85.0 KByte (default)
————————————————————
[ 3] local 10.134.16.230 port 51345 connected with 112.131.5.76 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-13.4 sec 7.75 MBytes 4.85 Mbits/sec
[root@fc18-atica ~]#

 

  • Duración del Test (por defecto 10).

La duración por defecto es 10. Se puede explicitar una duración mayor con el argumento t.

iperf -c ipserver -t 60 (duración 60 sgs).

root@observium:/etc# iperf -c 112.131.5.76 -t 3    (duración total de 3sgs).
————————————————————
Client connecting to 212.231.5.76, TCP port 5001
TCP window size: 23.5 KByte (default)
————————————————————
[ 3] local 172.0.0.14 port 44967 connected with 112.131.5.76 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 3.0 sec 323 MBytes 902 Mbits/sec
root@observium:/etc#

 

  • Intervalo de tiempo durante el que se mide (ancho de banda, jitter, y packet loss).

Por defecto es cero. En este caso hay un único reporte.

iperf -c ip_server -i 2

root@observium:/etc# iperf -c 112.131.5.76 -t 6 -i1
————————————————————
Client connecting to 212.231.5.76, TCP port 5001
TCP window size: 23.5 KByte (default)
————————————————————
[ 3] local 172.0.0.14 port 44968 connected with 112.131.5.76 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 99.6 MBytes 836 Mbits/sec
[ 3] 1.0- 2.0 sec 102 MBytes 851 Mbits/sec
[ 3] 2.0- 3.0 sec 102 MBytes 854 Mbits/sec
[ 3] 3.0- 4.0 sec 102 MBytes 856 Mbits/sec
[ 3] 4.0- 5.0 sec 102 MBytes 860 Mbits/sec
[ 3] 5.0- 6.0 sec 102 MBytes 852 Mbits/sec
[ 3] 0.0- 6.0 sec 609 MBytes 851 Mbits/sec
root@observium:/etc#

 

  • Conexión bidireccional.

Se comprueba la velocidad en un sentido y luego en el otro.

Se utiliza el argumento r para comprobar la dirección en un sentido y luego en el otro. Primero desde el servidor al cliente y luego en sentido contrario. Con el argumento d sería el orden al revés.

iperf -c ip_servidor -r .

 

  • Cambiar protocolo udp en lugar tcp.

Por defecto Iperf usa TCP. Si se desea utilizar UDP debe utilizarse tanto en el servidor como en el cliente el argumento u.

iperf -c ip_server -u

iperf -s -u

El resultado contendrá una métrica extra para el packet loss. Esta debe ser lo más pequeña posible como es natural.

 

  • Lanzar múltiples threads
Iperf -c ip_server -P4

  • Comprobar la versión de Iperf

Se utiliza el argumento v para comprobar la versión del iperf.

root@server:/home/ubuntu# iperf -v
iperf version 2.0.5 (08 Jul 2010) pthreads

  • Ayuda Iperf.

Se utiliza el argumento h para comprobar toda la lista de argumentos soportados por iperf.

Passwordless SSH

  • admin 

Passwordless SSH can be accomplished using SSH’s public key authentication. To configure passwordless SSH, follow the directions below. Warning: passwordless SSH will make your systems less secure. If you are comfortable with that, the directions below will walk you through server and client configurations. Then, I’ll show you how to debug SSH if you encounter problems.

SSHD Server Configuration

First, you must ensure that your SSHD server allows for passwordless authentication using public keys. If you do not have root access to the server, do not worry. By default, public key authentication over protocol 2 is enabled. Skip this step. If you have any problems, contact your System Administrator.

If you have root privileges, edit your system’s /etc/ssh/sshd_config and apply the following settings. I suggest you disable protocol 1 RSA key based authentication and leave all other settings alone for now. Visit the man page SSHD_CONFIG(5) for details.

# Disable protocol 1 RSA key based authentication
RSAAuthentication no
# Protocol 2 public key based authentication
PubkeyAuthentication yes
# Authorized public keys file
AuthorizedKeysFile .ssh/authorized_keys

If you make any changes, save them and restart your SSH server.

service sshd restart

SSH Client Configuration

Now that the server is configured, log into your client system and examine /etc/ssh/ssh_config. This is the SSH client configuration file and you do not need to edit it.

less /etc/ssh/ssh_config

By default, public key authentication over protocol 2 is enabled for clients. You only need to make sure that it is not disabled. If it is, create an ~/.ssh/config to override the /etc/ssh/ssh_config options.

cp -a /etc/ssh/ssh_config ~/.ssh/config

Then edit it and add this to the «Host *» block:

PubkeyAuthentication yes

Create Client Key

With the client in order, you need to create a public and private key pair. The following command will build a DSA key pair. Hit for all questions asked. This will create a DSA key pair in ~/.ssh/. The private key is called id_dsa and the public key is id_dsa.pub.

ssh-keygen -t dsa

Use Key for Authentication

Now that you have a public and private key pair, put the public key on the server you wish to log into without a password. You will need to put the public key inside the server’s /home/user/.ssh/authorized_keys file. This file can contain multiple keys, so you generally do not want to just copy over it. Note that the authorized_keys2 file was deprecated in OpenSSH 3.0 (2001).

cat ~/.ssh/id_dsa.pub | ssh user@server "cat - >> ~/.ssh/authorized_keys"

Alternatively, modern releases of SSH have a command to help you copy keys.

ssh-copy-id -i ~/.ssh/id_dsa.pub user@server

Test and Debug SSH

Now, test.

ssh username@server date

If you get prompted for a password, check the server’s system logs for clues. You can also enable debugging in /etc/ssh/sshd_config with the following directive.

LogLevel DEBUG

Other options are INFO, VERBOSE, DEBUG2 and DEBUG3. See the man page SSHD_CONFIG(5) for details. For the client, the exact same option can be placed inside a /etc/ssh/ssh_config’s Host block. See SSH_CONFIG(5) for client debugging details.

man 5 sshd_config
man 5 ssh_config

 

Fuente: http://hacktux.com/passwordless/ssh