En la edición 2017 de la Global Azure Bootcamp servidor hospedó en Azure un servidor de TetriNET dockerizado disponible para todo el que quisiera conectarse.

Este año vamos a mantenerlo pero con una vuelta de tuerca adicional: estará hospedado en Azure Kubernetes Service. Con el contendor del servidor ya desarrollado, la adaptación a AKS ha sido trivial y meramente basada en construir las declaraciones YAML necesarias para Kubernetes. Aún así creo que es lo suficientemente relevante para mencionarlo en un artículo.

Para este propósito he creado dos YAML, uno que crea el Service y el Secret donde irán las password de administrador del servicio y un segundo con el Deployment.

El motivo de esta división es que, como vamos a ver, el tipo del Service es LoadBalancer, ya que AKS se encargará de gestionarlo. La creación del balanceador de carga y sus reglas le lleva a Azure unos pocos minutos y nuestro Deployment se quejará amargamente y dará error si su Service no está en funcionamiento previamente. A diferencia de las plantillas JSON de ARM, no parece que haya forma de especificar dependencias dentro de un mismo YAML de Kubernetes, por lo que no queda más remedio que dividir la implementación en dos archivos y lanzarlos secuencialmente tras un tiempo prudencial. Agradeceré que me dejéis ideas y/o comentarios a este respecto.

Antes de continuar, os recuerdo que vamos usar la imagen Docker que ya construimos para la Global Azure Bootcamp 2017.

tetrinetx-aks-1.yaml

Lo primero es definir el Service, que será la IP estable y conocida mediante la cual nos podremos conectar a nuestro servidor. Una vez más, los Pods que se encuentran bajo un Deployment son susceptibles de cambiar dinámicamente y su red agnóstica a nosotros.

apiVersion: v1
kind: Service
metadata:
  name: tetrinetx
  labels:
    app: tetrinetx
spec:
  ports:
    - name: http
      protocol: TCP
      port: 80
    - name: tetrinet
      protocol: TCP
      port: 31457
    - name: tetrispec
      protocol: TCP
      port: 31458
  selector:
    app: tetrinetx
  type: LoadBalancer
  loadBalancerIP: 52.174.54.111
  clusterIP: 10.0.1.1 # Default range: 10.0.0.0/16
---
apiVersion: v1
kind: Secret
metadata:
  name: tetrinetx
  labels:
    app: tetrinetx
type: Opaque
data:
  op-pwd: cDRzc3cwcmQK # p4ssw0rd in base64
  spec-pwd: cDRzc3cwcmQK # p4ssw0rd in base64

Ningun misterio aquí: definimos los labels del selector y los puertos disponbiles para la conexión. Como siempre, ClusterIP será la IP interna estable de nuestro servidor, mientras que loadBalancerIP será la pública del Azure Load Balancer, atributo que por cierto es opcional, siendo este un matiz importante.

Si la definición especificamos type como LoadBalancer, pero no definimos loadBalancerIP, el servicio se creará con una IP aleatoria que Azure le asigne al balanceador de carga.

En cambio, si hemos definido loadBalancerIP, Azure nos asignará dicha IP siempre que el recurso de Public IP que la contenga haya sido creado previamente y se encuentre en el mismo grupo de recursos que el cluster de AKS. Así que no, no podemos pedirle a Azure la dirección IP pública que queramos.

En cuanto al Secret sólo mencionar que las contraseñas se especifican en base64.

tetrinetx-aks-2.yaml

Ahora hacemos la definicion del Deployment, que quedaría tal que así:

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2, before 1.8.0 use apps/v1beta1
kind: Deployment
metadata:
  name: tetrinetx
  labels:
    app: tetrinetx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tetrinetx
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: tetrinetx
    spec:
      hostname: tetrinet
      subdomain: azurebootcamp
      containers:
      - image: cmilanf/tetrinetx
        imagePullPolicy: Always
        name: tetrinetx
        env:
        - name: OP_PASSWORD
          valueFrom:
            secretKeyRef:
              name: tetrinetx
              key: op-pwd
        - name: SPEC_PASSWORD
          valueFrom:
            secretKeyRef:
              name: tetrinetx
              key: spec-pwd
        ports:
        - containerPort: 80
          name: http
        - containerPort: 31457
          name: tetrinetx
        - containerPort: 31458
          name: tetrispec

Notas sobre esta declaración:

  • Tetrinetx nunca se diseñó para escalar, así que el número de réplicas por defecto es 1. ¿Significa esto que no podemos escalarlo a -por ejemplo- 200 instancias? Para nada, desde luego que podemos, pero serán totalmente independientes y los jugadores acabarán en una u otra sin control alguno; algo que no es muy deseable.
  • Bajo spec tenemos la plantilla de definición del Pod que se va a crear a partir de este Deployment.
  • Las líneas 19 y 20 son para la especificación de un hostname, que era un requisito de Tetrinetx que ya teníamos que afrontar desplegándolo en bruto mediante Docker.
  • La línea 22 indica la imagen Docker que vamos a utilizar en los Pods y como no estamos especificando nada especial, por defecto buscará en el repositorio público oficial de Docker, es decir descargará esta imagen.
  • La línea 23 especifica que siempre iremos al repositorio pertinente a descargar la imagen ante una reimplementación del Pod. Es muy útil para testing y desarrollo, pero se debe manejar con cuidado en entornos productivos, en especial si nuestras imágenes son grandes.
  • Especificamos variables y puertos, al igual que ya hacíamos con Docker.

Resultado

Es el siguiente:

C:\>kubectl get secrets -l app=tetrinetx
NAME        TYPE      DATA      AGE
tetrinetx   Opaque    2         9d

C:\>kubectl get service -o wide -l app=tetrinetx
NAME        TYPE           CLUSTER-IP   EXTERNAL-IP     PORT(S)                                        AGE       SELECTOR
tetrinetx   LoadBalancer   10.0.1.1     52.174.xxx.xxx   80:31888/TCP,31457:31255/TCP,31458:30115/TCP   9d        app=tetrinetx

C:\>kubectl get deployment -o wide -l app=tetrinetx
NAME        DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE       CONTAINERS   IMAGES              SELECTOR
tetrinetx   1         1         1            1           9d        tetrinetx    cmilanf/tetrinetx   app=tetrinetx

C:\>kubectl get pods -o wide -l app=tetrinetx
NAME                         READY     STATUS    RESTARTS   AGE       IP            NODE
tetrinetx-8559b876c7-8x9d7   1/1       Running   0          9d        10.244.xxx.xxx   aks-nodepool1-393643750-0

Podemos dirigirnos a http://tetrinet.azurebootcamp.es o http://tetrinet.calnus.com, descargar nuestro cliente y apuntarlo a tetrinet.azurebootcamp.es o tetrinet.calnus.com.

Happy tetrit!