El propósito de este proyecto consiste en generar los objetos kubernetes en base a la imagen del nodo del repositorio oficial bfanodo para el despliegue sobre las plataformas de contenedores.
En este caso se verifico el funcionamiento en Sandbox RedHat OpenShift Dedicated (Openshift 4.9) sincronizando con la red de pruebas testnet.
Autenticacar con el cliente del cluster, clonar el repositorio e importar todos los objetos k8s en el namespace donde se creará el proyecto.
kubectl apply -f k8s/ . -n $NAMESPACE
Existen dos tipos de dockerfile en el repositorio, el que toma de base la imagen del nodo en testnet y el que toma de base el cliente Ethereum clona el núcleo bfa y genera la instalación.
# local
docker build -t nodo-bfa .
También existe una configuración por medio de la clave dockerfile desde el objeto BuildConfig.
# k8s/buildconfig.yaml
kind: BuildConfig
apiVersion: build.openshift.io/v1
metadata:
name: nodo-bfa-core-fork
spec:
nodeSelector: null
output:
to:
kind: ImageStreamTag
name: 'nodo-bfa-core-fork:test'
resources: {}
successfulBuildsHistoryLimit: 5
failedBuildsHistoryLimit: 5
strategy:
type: Docker
dockerStrategy: {}
postCommit: {}
source:
type: Git
git:
uri: 'https://gitlab.bfa.ar/docker/bfanodo.git'
ref: master
contextDir: "bfatoolbase"
dockerfile: "FROM bfaar/nodo:test \nUSER root \nRUN chown 30303:0 ${BFAHOME} && chgrp -R 0 ${BFAHOME} && chmod -R g=u ${BFAHOME} \nUSER bfa"
runPolicy: Serial
Las imagenes se agregan en el paso de kubectl appy, se recomienda hacer un pull a registry internal por el limite de descargas de dockerhub a fines de pruebas.
# k8s/imagestream.yaml
kind: ImageStream
apiVersion: image.openshift.io/v1
metadata:
name: nodo-bfa
labels:
app: nodo-bfa
app.kubernetes.io/component: nodo-bfa
app.kubernetes.io/instance: nodo-bfa
app.kubernetes.io/name: nodo-bfa
app.kubernetes.io/part-of: nodo-bfa
spec:
lookupPolicy:
local: false
tags:
- name: test
annotations:
openshift.io/imported-from: 'bfaar/nodo:test'
from:
kind: DockerImage
name: 'bfaar/nodo:test'
generation: 2
importPolicy: {}
referencePolicy:
type: Local
Es necesario persistir la blockchain, sin importar la red a la que se sincronize, por medio de un volumen persistente, el pvc se genera en el import de /k8s, tengan en cuenta el storage segun los requerimientos del tipo de nodo gateway a desplegar es de 300Gi minimo (15Gi es el limite maximo en el cluster sandbox) y en crecimiento continuo.
# k8s/pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-bfa
spec:
accessModes:
- ReadWriteOnce
volumeMode: Filesystem
resources:
requests:
storage: 15Gi
Con kubectl apply se crearán los configmap docker-config y env, se montarán en DeploymentConfig como volumen.
# k8s/deploymentconfig.yaml
volumeMounts:
- name: docker-config
mountPath: /home/bfa/bfa/test2network/docker-config.toml
subPath: docker-config.toml
- name: env
mountPath: /home/bfa/bfa/bin/env
subPath: env
Para la implementacion de CI/CD a partir los eventos de repositorios se deberán generar secret y webhook) para clonar el repositorio en caso de necesitar hacer un fork.
# k8s/secret.yaml
kind: Secret
apiVersion: v1
metadata:
name: gittoken
data:
password: maximilianoPizarro
username: token
type: kubernetes.io/basic-auth
# k8s/secret.yaml
kind: Secret
apiVersion: v1
metadata:
name: hookbfa
data:
WebHookSecretKey: hooksecret
type: Opaque
El user por defecto de la imagen base del nodo corresponde al 30303 (bfa), para generar un contexto de id arbitrario en Openshift se agrego el step para poder asignarlo en el Dockerfile del repo segun las mejores prácticas de creación de contenedores de la documentación oficial de redhat. En caso de querer generar el pull directo desde dockerhub será requisito aplicar el SCC con el siguiente comando.
# requiere permisos cluster-admin (no disponibles en el cluster sandbox)
oc adm policy add-scc-to-user 30303 system:serviceaccount:$NAMESPACE:default
Cada transacción es ingestada sobre plataforma Blockchain Federal Argentina en una fecha cierta por medio de nodos transaccionales registrados en bfa.ar a través de un Smart Contract llamado TIME STAMP AUTHORITY que se encuentra desplegado en la red de pares de nodos de Clientes Ethereum con dos únicas operaciones disponibles get y put del digesto criptográfico. El sello de tiempo es un servicio de la plataforma en donde cualquier usuario registrado o no puede consultar si el hash de un documento existe en la cadena de bloques informando fecha cierta, autoría y bloque de la transacción. Conoce más ingresando a página #BlockchainFederalArgentina #Sumate #TransformaciónDigital
🔭 Red BFA | |
---|---|
📫 Personal: | |