Cloudflare Argo Tunnel accessible gratuitement aux développeurs : mise en oeuvre avec k3s …
Je pars pour cette expérience d’un Scale Set dans Azure avec une instance Ubuntu 18.04 LTS de type Ev3 qui autorise la virtualisation imbriquée :
et je vais déployer DevStack via ce fichier de paramètres local.conf :
et ces étapes :
$ sudo apt install libvirt-bin bridge-utils
$ sudo service libvirtd start
$ sudo update-rc.d libvirtd enable
$ sudo useradd -s /bin/bash -d /opt/stack -m stack
$ echo "stack ALL=(ALL) NOPASSWD: ALL" | sudo tee /etc/sudoers.d/stack
$ sudo su - stack
$ git clone [https://git.openstack.org/openstack-dev/devstack](https://git.openstack.org/openstack-dev/devstack) -b stable/stein
$ cd devstack
$ wget -c [https://gist.githubusercontent.com/deep75/ff0201f0bcf29906881ebce3f106e173/raw/18874bf7291f97687af3990e8c1dc517ac29706a/local.conf](https://gist.githubusercontent.com/deep75/ff0201f0bcf29906881ebce3f106e173/raw/18874bf7291f97687af3990e8c1dc517ac29706a/local.conf)
$ ./stack.sh
Le cluster OpenStack est accessible depuis cette instance Azure dans ce Scale Set avec l’adresse IP publique :
Après import d’une image Ubuntu dans Glance :
$ . openrc
$ wget -c [https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img](https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64.img)
$ glance --os-image-api-version 2 image-create --name 'Ubuntu 18.04 LTS 64 Bits' --disk-format qcow2 --container-format bare --file ./bionic-server-cloudimg-amd64.img --progress
Je lance 4 instances :
à l’aide de ce fichier cloud-init simple :
#!/bin/sh
curl -fsSL [https://get.docker.com](https://get.docker.com) -o get-docker.sh
sh get-docker.sh
sudo usermod -aG docker ubuntu
et je peux créer mon petit cluster K8S avec K3S :
avec la particularité d’utiliser Docker en lieu et place de Containerd et sans agent ni Traefik sur le noeud maître :
$ nohup sudo k3s server --disable-agent --no-deploy traefik --docker &
Je raccorde deux noeuds worker à ce cluster :
$ nohup sudo k3s agent --server [https://11.14.15.146:6443](https://11.14.15.146:6443) --token K10a452672c09f560d734d4565ea32093e75d17ba1c31ab7c05bbe74780b346c2b7::node:7b3a469d8e5b5c3c6b8948302d718281 --docker &
Le cluster est disponible avec ces noeuds :
Je lance une instance avec Rancher Server et j’importe ce nouveau cluster :
Je lance le désormais célèbre démonstrateur FC avec Rancher avec NodePort :
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: fcdemo-agent-app
annotations:
flux.weave.works/automated: 'true'
spec:
replicas: 4
template:
metadata:
labels:
app: fcdemo-agent-app
spec:
containers:
- name: fcdemo-agent-app
image: mcas/franceconnect-agent-demo:latest
ports:
- containerPort: 8000
---
apiVersion: v1
kind: Service
metadata:
name: fcdemo-agent-service
labels:
app: fcdemo-agent-service
spec:
type: **NodePort**
ports:
# the port that this service should serve on Kubernetes
- port: 80
targetPort: 8000
protocol: TCP
selector:
app: fcdemo-agent-app
Ceci émet sur port TCP 32302 sur tous les noeuds du Cluster. Je lance alors un Load Balancer avec Octavia :
J’ai donc une Floating IP qui pointe vers ce pool de noeuds du cluster K3S sur le port 80. Je vais utiliser Cloudflare Argo Tunnel pour exposer publiquement le démonstrateur FC. En effet, Cloudflare a rendu accessible sa solution de tunneling pour les développeurs :
$ wget -c [https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-amd64.deb](https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-amd64.deb)
$ sudo dpkg -i cloudflared-stable-linux-amd64.deb
$ curl [http://192.168.122.234](http://192.168.122.234)
$ nohup sudo cloudflared tunnel --url [http://192.168.122.234](http://192.168.122.234) &
J’obtiens un lien URL qui me permet d’accéder publiquement au démonstrateur FC :
Par le biais du stockage objet avec Swift, je peux avoir accès publiquement à divers fichiers comme une vidéo :
Pour finir, toujours en test, je peux lancer un petit clone de Youtube open source sans prétention via cette image Docker :
Toujours via Argo Tunnel, je peux le rendre accessible publiquement :
Il est possible d’utiliser Argo tunnel comme Ingress Controller dans un cluster Kubernetes (mais avec abonnement) :
Kubernetes Ingress Controller - Argo Tunnel
$ helm repo add cloudflare https://cloudflare.github.io/helm-charts
$ helm repo update
$ helm install --name anydomain --namespace default \
--set rbac.create=true \
--set controller.ingressClass=argo-tunnel \
--set controller.logLevel=6 \
cloudflare/argo-tunnel
et ce type de définition pour le manifest :
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: argo-tunnel
labels:
ingress: argo-tunnel
name: echo
spec:
tls:
- hosts:
- echo.mydomain.com
secretName: mydomain.com
rules:
- host: echo.mydomain.com
http:
paths:
- backend:
serviceName: echo
servicePort: http
Si je ne veux pas dépendre d’Argo Tunnel, je peux opter pour les nombreuses alternatives comme par exemple Serveo qui propose une implémentation on-premise :
Serveo: expose local servers to the internet using SSH
Je pars d’une micro instance dans Outscale avec cette variante :
outscale@ip-10-9-5-245:~$ **wget -c** [**https://storage.googleapis.com/serveo/download/2018-05-08/serveo-linux-amd64**](https://storage.googleapis.com/serveo/download/2018-05-08/serveo-linux-amd64)
--2019-06-19 14:40:53-- [https://storage.googleapis.com/serveo/download/2018-05-08/serveo-linux-amd64](https://storage.googleapis.com/serveo/download/2018-05-08/serveo-linux-amd64)
Resolving storage.googleapis.com (storage.googleapis.com)... 172.217.22.144, 2a00:1450:4007:815::2010
Connecting to storage.googleapis.com (storage.googleapis.com)|172.217.22.144|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3145352 (3.0M) [application/octet-stream]
Saving to: ‘serveo-linux-amd64’
serveo-linux-amd64 100%[========================================================================\>] 3.00M --.-KB/s in 0.04s
2019-06-19 14:40:53 (76.8 MB/s) - ‘serveo-linux-amd64’ saved [3145352/3145352]
outscale@ip-10-9-5-245:~$ **chmod +rwx serveo-linux-amd64**
outscale@ip-10-9-5-245:~$ **sudo mv serveo-linux-amd64 /usr/local/bin/serveo**
outscale@ip-10-9-5-245:~$ **vim key.rsa**
outscale@ip-10-9-5-245:~$ **chmod 400 key.rsa**
outscale@ip-10-9-5-245:~$ **sudo serveo -private\_key\_path=key.rsa -port=2222 -http\_port=80 -https\_port=443 -domain=171-33-99-243.sslip.io**
Listening on :2222...
J’ai lancé le serveur Serveo sur un domaine Wild Card pour l’exemple …
Depuis mon instance sur le Scale Set, je peux lancer un tunnel persistant via Autossh vers le serveur Serveo depuis le load Balancer HAProxy généré précédemment avec Octavia :
$ **eval "$(ssh-agent -s)"**
Agent pid 6770
$ **ssh-add ./key.rsa**
Identity added: ./key.rsa (./key.rsa)
$ **sudo apt install autossh**
$ **autossh -p 2222 -M 0 -R fc:80:192.168.122.234:80 171-33-99-243.sslip.io**
Warning: Permanently added '[171-33-99-243.sslip.io]:2222,[171.33.99.243]:2222' (RSA) to the list of known hosts.
Warning: no TLS certificate available for fc.171-33-99-243.sslip.io. You won't be able to use HTTPS, only HTTP.
Forwarding HTTP traffic from [**http://fc.171-33-99-243.sslip.io**](http://fc.171-33-99-243.sslip.io)
Press g to start a GUI session and ctrl-c to quit.
J’accède alors au démonstrateur via ce Tunnel et ce domaine Wild Card DNS (via sslip.io) :
Tout ceci peut être très utile pour la réalisation d’environnement de test par exemple …
A suivre !
Top comments (0)