Subutai – Construa sua Nuvem com Blockchain – Parte 2 de 2

Olá, e obrigado pela sua visita. Esta é a segunda e última parte do nosso artigo sobre a plataforma de computação em nuvem distribuída Subutai. Se você não leu a primeira parte, clique aqui.

 

PeerOS

Ativei 3 VMs com Debian para executar o PeerOS. Todas elas precisam de atualização. Não consegui encontrar nenhum local central para conduzir a atualização. Assim, precisai fazer individualmente em cada um. Entrei na interface gráfica de cada peer e iniciei o processo. Isto pode ser feito através do Bazaar. Você pode verificar o status de cada peer e escolher conectar às suas interfaces gráficas individuais. O HTTPS sempre é usado.

Quando você instala o PeerOS, incluindo o servidor NGINX interno, um usuário “admin” é automaticamente criado com a senha “subutai”. O primeiro login é sucedido por um quadro “change password”. Portanto, você precisa alterá-la. Isto é crucial, pois a interface gráfica fica exposta à Internet. Nunca ignore uma atualização e mudança de senha!

O Control Center mostra as mudanças de status com base nas atualizações. Naturalmente, durante estas operações, o PeerOS será reiniciado e você não poderá usar o peer. Você pode acompanhar de perto o processo verificando o arquivo “/var/log/messages” no peer.

O PeerOS é uma solução baseada em Java que representa o cérebro do sistema de computação em nuvem Subutai. As tarefas que você executa no PeerOS são implementadas usando o conceito CaaS (Container as a Service). Portanto, suas aplicações serão automaticamente postas em containers usando LXC (Linux Containers).

O PeerOS também com o daemon P2P e um cache CDN assim como sua própria console gráfica, como falei anteriormente. A Figura 10 mostra parte da tela principal da console de um peer.

O software requer algumas portas abertas para funcionar. Se você está usando algum firewall (iptables ou qualquer outro) no host, você precisa criar regras para liberar as referidas portas. Verifique se elas não estão em uso por algum processo existente e se o firewall não vai bloqueá-las.

A documentação é muito concisa no que diz respeito à instalação de qualquer componente. Uma coisa à qual você deve prestar atenção é a parte de armazenamento. Você precisa de um disco com, pelo menos, 100 GB de espaço livre. E mais: você não terá como usar esta área para outra coisa além do PeerOS. Ele usa o ZFS para manipular o espaço. Assim, durante a instalação, você usará ferramentas do ZFS para criar e mapear a área de armazenamento. Atualmente, o ZFS foi substituído pelo OpenZFS.

Depois que os peers estiverem atualizados e online, posso criar um environment, que me permitirá usar minhas aplicações. Esta criação de ambiente precisa do upload de um fingerprint PGP. Há várias ferramentas para gerar esse par de chaves. Escolha uma de sua preferência. Depois disso, faça upload na caixa de diálogo correspondente. Veja a Figura 11.

Pode ser que apareça a imagem da Figura 12. É apenas para pedir autorização formal de usar seu par de chaves PGP na CDN. Apenas clique “Authorize”.

Meu laboratório está executando na Oracle Ravello. Como sou vExpert, tenho direito a algumas horas gratuitas mensais de CPU neste ambiente. Então, conforme recomendado pela documentação do PeerOS, configurei meu ambiente para usar o Debian Stretch. A documentação oficial do produto diz que qualquer distribuição Linux pode ser usada, mas esta em particular foi particularmente bem testada com o PeerOS. Veja meu diagrama na Figura 13.

A seta verde significa que a VM está em execução. Todas as tags azuis que aparecem dos lados esquerdos das VMs significam todas as portas que estão liberadas para acesso externo. Como todas as comunicações no Subutai funcionam autenticadas e criptografadas, não precisa se preocupar quanto a isso.

Depois de autorizar a CDN com meu keypair, decidi criar alguns environments. Ao fazer isso, você precisa escolher, pelo menos, um de seus peers. Depois de escolher, é necessário selecionar pelo menos um dos templates disponíveis. Alguns dos que constavam quando escrevi este artigo eram: Jenkins, Golang, Ansible, MariaDB, e outros. Cada peer pode ter até quatro templates em execução simultaneamente. Cada template corresponde a um container LXC em execução. Posteriormente, adicionarei outro peer a este environment. Isto será apenas para demonstrar que posso iniciar uma tarefa num peer que não está sob meu controle (um peer qualquer de outro usuário).

Para o primeiro environment, escolhi executar o Golang com o Jenkins no meu peer subu0, e dei o nome “Go_Jenkins” para este environment. Ao nomear um environment, use apenas letras e o caracter underline “_”. O processo gera bastante log, e você pode verificar o arquivo “/var/log/messages”. Observe a saída abaixo:

subu0 kernel: [  783.776532] tun: Universal TUN/TAP device driver, 1.6
subu0 kernel: [  783.776533] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
subu0 NetworkManager[1524]: <info>  [1527473784.4480] manager: (p2p1): new Tun device (/org/freedesktop/NetworkManager/Devices/7)
subu0 NetworkManager[1524]: <info>  [1527473784.5032] devices added (path: /sys/devices/virtual/net/p2p1, iface: p2p1)
subu0 NetworkManager[1524]: <info>  [1527473784.5033] device added (path: /sys/devices/virtual/net/p2p1, iface: p2p1): no ifupdown configuration found.
subu0 NetworkManager[1524]: <info>  [1527473784.5069] device (p2p1): state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41]
subu0 NetworkManager[1524]: <info>  [1527473784.5162] keyfile: add connection in-memory (1d4b8bbb-284f-4d4c-a736-c779b0fe63ba,"p2p1")
subu0 NetworkManager[1524]: <info>  [1527473784.5185] device (p2p1): state change: unavailable -> disconnected (reason 'connection-assumed') [20 30 41]
subu0 NetworkManager[1524]: <info>  [1527473784.5193] device (p2p1): Activation: starting connection 'p2p1' (1d4b8bbb-284f-4d4c-a736-c779b0fe63ba)
subu0 NetworkManager[1524]: <info>  [1527473784.5198] device (p2p1): state change: disconnected -> prepare (reason 'none') [30 40 0]
subu0 NetworkManager[1524]: <info>  [1527473784.5264] device (p2p1): state change: prepare -> config (reason 'none') [40 50 0]
subu0 NetworkManager[1524]: <info>  [1527473784.5267] device (p2p1): state change: config -> ip-config (reason 'none') [50 70 0]
subu0 NetworkManager[1524]: <info>  [1527473784.5707] device (p2p1): state change: ip-config -> ip-check (reason 'none') [70 80 0]
subu0 NetworkManager[1524]: <info>  [1527473784.6091] device (p2p1): state change: ip-check -> secondaries (reason 'none') [80 90 0]
subu0 NetworkManager[1524]: <info>  [1527473784.6177] device (p2p1): state change: secondaries -> activated (reason 'none') [90 100 0]
subu0 NetworkManager[1524]: <info>  [1527473784.6212] device (p2p1): Activation: successful, device activated.
subu0 subutai[6101]: time="2018-05-27 23:16:45" level=info msg="Template's owner signature verified"
subu0 subutai[6101]: time="2018-05-27 23:16:45" level=info msg="Version: 0.4.1"
subu0 subutai[6101]: time="2018-05-27 23:16:45" level=info msg="Importing jenkins"
subu0 subutai[6101]: time="2018-05-27 23:16:45" level=info msg="Downloading jenkins"
subu0 subutai[6093]: time="2018-05-27 23:16:45" level=info msg="Template's owner signature verified"
subu0 subutai[6093]: time="2018-05-27 23:16:45" level=info msg="Version: 0.4.1"
subu0 subutai[6093]: time="2018-05-27 23:16:45" level=info msg="Importing golang"
subu0 subutai[6093]: time="2018-05-27 23:16:45" level=info msg="Downloading golang"
subu0 subutai[6759]: time="2018-05-27 23:19:48" level=info msg="No update is available"
subu0 subutai[7134]: time="2018-05-27 23:19:52" level=info msg="No update is available"
subu0 subutai[6093]: time="2018-05-27 23:20:14" level=info msg="File integrity is verified"
subu0 subutai[6093]: time="2018-05-27 23:20:14" level=info msg="Unpacking template golang"
subu0 /usr/bin/subutai[1983]: time="2018-05-27 23:20:17" level=warning msg="listen udp4 0.0.0.0:1900: bind: address already in use"
subu0 subutai[6101]: time="2018-05-27 23:20:44" level=info msg="File integrity is verified"
subu0 subutai[6101]: time="2018-05-27 23:20:44" level=info msg="Unpacking template jenkins"
subu0 subutai[6093]: time="2018-05-27 23:20:45" level=info msg="Installing template golang"
subu0 kernel: [ 1110.718122] IPv6: ADDRCONF(NETDEV_UP): 00163ed80ad1: link is not ready
subu0 NetworkManager[1524]: <info>  [1527474111.3746] manager: (veth69DVME): new Veth device (/org/freedesktop/NetworkManager/Devices/8)
subu0 NetworkManager[1524]: <info>  [1527474111.3851] manager: (00163ed80ad1): new Veth device (/org/freedesktop/NetworkManager/Devices/9)
subu0 NetworkManager[1524]: <info>  [1527474111.4377] devices added (path: /sys/devices/virtual/net/00163ed80ad1, iface: 00163ed80ad1)
subu0 NetworkManager[1524]: <info>  [1527474111.4377] device added (path: /sys/devices/virtual/net/00163ed80ad1, iface: 00163ed80ad1): no ifupdown configuration found.
subu0 NetworkManager[1524]: <info>  [1527474111.4584] devices added (path: /sys/devices/virtual/net/veth69DVME, iface: veth69DVME)
subu0 NetworkManager[1524]: <info>  [1527474111.4584] device added (path: /sys/devices/virtual/net/veth69DVME, iface: veth69DVME): no ifupdown configuration found.
subu0 kernel: [ 1110.830847] device gw-1 entered promiscuous mode
subu0 NetworkManager[1524]: <info>  [1527474111.4852] manager: (gw-1): new Generic device (/org/freedesktop/NetworkManager/Devices/10)
subu0 NetworkManager[1524]: <info>  [1527474111.5291] devices added (path: /sys/devices/virtual/net/gw-1, iface: gw-1)
subu0 NetworkManager[1524]: <info>  [1527474111.5291] device added (path: /sys/devices/virtual/net/gw-1, iface: gw-1): no ifupdown configuration found.
subu0 NetworkManager[1524]: <info>  [1527474111.5540] device (00163ed80ad1): enslaved to non-master-type device ovs-system; ignoring
subu0 kernel: [ 1110.901308] device 00163ed80ad1 entered promiscuous mode
subu0 NetworkManager[1524]: <info>  [1527474111.5641] device (gw-1): link connected
subu0 NetworkManager[1524]: <info>  [1527474111.6866] device (00163ed80ad1): enslaved to non-master-type device ovs-system; ignoring
subu0 NetworkManager[1524]: <info>  [1527474111.6998] devices removed (path: /sys/devices/virtual/net/veth69DVME, iface: veth69DVME)
subu0 kernel: [ 1111.050277] eth0: renamed from veth69DVME
subu0 kernel: [ 1111.064470] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
subu0 kernel: [ 1111.066509] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
subu0 kernel: [ 1111.066531] IPv6: ADDRCONF(NETDEV_CHANGE): 00163ed80ad1: link becomes ready
subu0 NetworkManager[1524]: <info>  [1527474111.7253] device (00163ed80ad1): link connected
subu0 NetworkManager[1524]: <info>  [1527474111.7254] device (00163ed80ad1): enslaved to non-master-type device ovs-system; ignoring
subu0 subutai[8059]: time="2018-05-27 23:21:51" level=info msg="Container-1-BSX-oeq-1-4 started"
subu0 subutai[8059]: time="2018-05-27 23:21:51" level=info msg="Container-1-BSX-oeq-1-4 with ID 995309AABCD6DF710B7F9C27DF628631F805173E successfully cloned"
subu0 kernel: [ 1113.097071] IPv6: ADDRCONF(NETDEV_UP): 00163e6155cb: link is not ready
subu0 NetworkManager[1524]: <info>  [1527474113.7520] manager: (vethTJ0SJJ): new Veth device (/org/freedesktop/NetworkManager/Devices/11)
subu0 NetworkManager[1524]: <info>  [1527474113.7616] manager: (00163e6155cb): new Veth device (/org/freedesktop/NetworkManager/Devices/12)
subu0 NetworkManager[1524]: <info>  [1527474113.8341] devices added (path: /sys/devices/virtual/net/00163e6155cb, iface: 00163e6155cb)
subu0 NetworkManager[1524]: <info>  [1527474113.8341] device added (path: /sys/devices/virtual/net/00163e6155cb, iface: 00163e6155cb): no ifupdown configuration found.
subu0 NetworkManager[1524]: <info>  [1527474113.8605] devices added (path: /sys/devices/virtual/net/vethTJ0SJJ, iface: vethTJ0SJJ)
subu0 NetworkManager[1524]: <info>  [1527474113.8606] device added (path: /sys/devices/virtual/net/vethTJ0SJJ, iface: vethTJ0SJJ): no ifupdown configuration found.
subu0 NetworkManager[1524]: <info>  [1527474113.8944] device (00163e6155cb): enslaved to non-master-type device ovs-system; ignoring
subu0 kernel: [ 1113.240394] device 00163e6155cb entered promiscuous mode
subu0 kernel: [ 1113.350970] eth0: renamed from vethTJ0SJJ
subu0 kernel: [ 1113.368415] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
subu0 kernel: [ 1113.370305] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
subu0 kernel: [ 1113.370330] IPv6: ADDRCONF(NETDEV_CHANGE): 00163e6155cb: link becomes ready
subu0 NetworkManager[1524]: <info>  [1527474114.0270] devices removed (path: /sys/devices/virtual/net/vethTJ0SJJ, iface: vethTJ0SJJ)
subu0 NetworkManager[1524]: <info>  [1527474114.0276] device (00163e6155cb): link connected
subu0 NetworkManager[1524]: <info>  [1527474114.0297] device (00163e6155cb): enslaved to non-master-type device ovs-system; ignoring
subu0 subutai[8071]: time="2018-05-27 23:21:54" level=info msg="Container-2-fhf-orm-1-3 started"
subu0 subutai[8071]: time="2018-05-27 23:21:54" level=info msg="Container-2-fhf-orm-1-3 with ID B5F928071DC07A694A5A9B7E3675516FEFA52F7A successfully cloned"
subu0 /usr/bin/subutai[1983]: time="2018-05-27 23:22:00" level=info msg="Getting public keyringkeyring/var/lib/lxc/Container-1-BSX-oeq-1-4/secret.sec"
subu0 /usr/bin/subutai[1983]: time="2018-05-27 23:22:01" level=info msg="Getting public keyringkeyring/var/lib/lxc/Container-2-fhf-orm-1-3/secret.sec"
subu0 /usr/bin/subutai[1983]: time="2018-05-27 23:22:17" level=warning msg="Recovered from panic in github.com/subutai-io/agent/agent/discovery.serverreflect: call of reflect.Value.Int on zero Value"
subu0 /usr/bin/subutai[1983]: time="2018-05-27 23:22:18" level=info msg="Getting public keyringkeyring/var/lib/lxc/Container-2-fhf-orm-1-3/secret.sec"
subu0 /usr/bin/subutai[1983]: time="2018-05-27 23:22:18" level=info msg="Getting public keyringkeyring/var/lib/lxc/Container-1-BSX-oeq-1-4/secret.sec"
subu0 /usr/bin/subutai[1983]: time="2018-05-27 23:22:18" level=info msg="Getting public keyringkeyring/var/lib/lxc/Container-1-BSX-oeq-1-4/secret.sec"
subu0 /usr/bin/subutai[1983]: time="2018-05-27 23:22:18" level=info msg="Getting public keyringkeyring/var/lib/lxc/Container-2-fhf-orm-1-3/secret.sec"
subu0 /usr/bin/subutai[1983]: time="2018-05-27 23:22:19" level=info msg="Getting public keyringkeyring/var/lib/lxc/Container-2-fhf-orm-1-3/secret.sec"
subu0 /usr/bin/subutai[1983]: time="2018-05-27 23:22:19" level=info msg="Getting public keyringkeyring/var/lib/lxc/Container-1-BSX-oeq-1-4/secret.sec"
subu0 /usr/bin/subutai[1983]: time="2018-05-27 23:22:19" level=info msg="Getting public keyringkeyring/var/lib/lxc/Container-1-BSX-oeq-1-4/secret.sec"
subu0 /usr/bin/subutai[1983]: time="2018-05-27 23:22:19" level=info msg="Getting public keyringkeyring/var/lib/lxc/Container-2-fhf-orm-1-3/secret.sec"
subu0 /usr/bin/subutai[1983]: time="2018-05-27 23:22:29" level=info msg="Getting public keyringkeyring/var/lib/lxc/Container-1-BSX-oeq-1-4/secret.sec"
subu0 /usr/bin/subutai[1983]: time="2018-05-27 23:22:30" level=info msg="Getting public keyringkeyring/var/lib/lxc/Container-2-fhf-orm-1-3/secret.sec"

Como escolhi implantar dois templates, ou seja, duas aplicações diferentes, o environment foi provisionado com dois containers. Olhe novamente a saída anterior. Você pode claramente perceber os dois containers sendo criados e obtendo seus respectivos endereços IP. É possível ter uma visão geral disso acessando a GUI do peer.

Observe que você pode escolher individualmente configurar um domínio, parar ou conectar-se a cada container via SSH. Na verdade, você nem precisa recorrer ao SSH. Basta apenas clicar no hostname do container, e você será redirecionado à console respectiva. Veja a Figura 15.

Finalmente, se você, como eu, prefere linha de comando, pode interagir com os containers executando comandos regulares LXC a partir do peer. No código abaixo, estou apresentando todos os containers em execução. Observe a existência de um container interno chamado “management”.

root@subu0:~# lxc-ls --running -f
NAME                    STATE   AUTOSTART GROUPS IPV4        IPV6
Container-1-BSX-oeq-1-4 RUNNING 0         -      172.26.48.4 -
Container-2-fhf-orm-1-3 RUNNING 0         -      172.26.48.3 -
management              RUNNING 0         -      10.10.10.1  -

Se você observar os sistemas de arquivos em seu peer, perceberá que o processo criou uma série de sistemas de arquivos efêmeros como parte do provisionamento de containers. Isso é normal quando lidando com containers LXC.

Bem, provisionei um container com Golang e outro com Jenkins. Como posso realmente saber que eles estão funcionando? É mais fácil ver no Golang. Apenas criei um código “Hello World”, compilei e o pus para executar. Conectei diretamente ao console do container usando o comando “lxc-attach”.

root@subu0:~# lxc-attach -n Container-1-BSX-oeq-1-4 -- /bin/bash
root@Container-1-BSX:~# vi test.go
root@Container-1-BSX:~# more test.go
package main
import "fmt"
func main() {
      fmt.Println("hello world")
    }
root@Container-1-BSX:~# /usr/local/go/bin/go run test.go
hello world
root@Container-1-BSX:~# /usr/local/go/bin/go build test.go
root@Container-1-BSX:~# ./test
hello world

O segundo container, com Jenkins, só pode testado quando você redireciona a sua porta (8080, por default) usando iptables de dentro do peer. Primeiro, você precisa descobrir qual é a NIC física do seu peer. Com o comando “lxc-ls” mostrado anteriormente, você já tem o endereço IP do container. Então, você só precisa fazer algo assim:

# iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 8080 -j DNAT --to 172.26.48.3:8080

No meu caso, “ens3” é a NIC do peer e “172.26.48.3” é o endereço IP do container. Você confirma se a operação deu certo ao tentar o acesso à interface gráfica do Jenkins. Aponte para o endereço do peer e use a porta 8080.

Meu outro teste prático se deu com o produto “Blockchain-in-a-Box”. Para fazê-lo, naveguei até a seção “Products” do Bazaar e escolhi fazer o Build deste. Observe a Figura 17. Se você clicar no botão “View”, terá acesso ao arquivo JSON correspondente a este produto, com os playbooks Ansible.

Este produto suporta apenas um peer. Então, escolhi o subu1 (minha segunda VM) para executá-lo. Depois de clicar no botão “Build”, ajustar algumas variáveis obrigatórias e selecionar o peer correto, simplesmente cliquei em “Finish” e assisti ao show. 🙂

A construção de um produto é um processo similar à criação manual de um environment e seleção de templates. Esta caixa Blockchain precisa de um container “large” para funcionar. Assim, como eu tinha dois peers completamente livres, nenhum peer externo foi necessário. Ela vem com um programa de carteira Ethereum chamado “Mist”, e um conjunto de ferramentas de desenvolvimento. Depois de provisionar o produto, dei uma olhada na console gráfica do meu peer para checar uso de CPU, memória e disco. Como você deve imaginar, um bom minerador de criptomoedas precisa de várias horas para gerar algo útil. Assim, deixarei meu laboratório alguns dias no ar para ver o resultado.

Observe a área azul no gráfico de CPU, Representa a medida de inatividade (idle). À medida que a área azul diminui, cresce a área verde (processos de usuário). Isto determina algum processamento na caixa.

Depois de quebrar bastante a cabeça com senhas e ter descoberto que este produto “Blockchain-in-a-Box” usa o Mate Desktop como seu Window Manager, pude finalmente conectar-me a ele usando a GUI. Instalei o X2Go-Client usando o Control Center e criei uma sessão. Dentro dele, instruí o software para iniciar um desktop personalizado e o comando “mate-session” para dar início à sessão. Além disso, precisei mudar a senha do usuário “x2go” do container, porque o keypair fornecido não foi suficiente para estabelecer a sessão. Na Figura 19, você pode ver a conexão no ar.

A aplicação de carteira Mist tem seu próprio ícone de desktop. Assim, basta disparar sua execução e, novamente, esperar. Ela faz download de blocos Ethereum e, após algum tempo, abre a tela principal para uso.

Simplesmente, abri as aplicações Mist e Visual Studio Code. O VSCode é instalado como uma das ferramentas de desenvolvimento, durante a construção do produto. Para mostrar o real funcionamento do conjunto, criei uma conta Ethereum. O próximo passo daqui é simplesmente começar a minerar moedas. 🙂

Como não havia nenhum peer gratuito durante este laboratório, tive que considerar minha terceira máquina virtual Debian (subu2) juntamente com um peer comercial externo (prod-peer-us-3) para executar meu terceiro e último environment. Criei um environment “WebSQL” e escolhi realizar o deploy de NGINX e MySQL nos peers. Um total de quatro containers foram criados para completar o environment. Novamente, tudo pode ser monitorado a partir do Bazaar, ou do log do peer.

É fácil verificar a redução de crédito GoodWill. Quando iniciei o environment anterior, o saldo era de 690 GoodWills. Assim que inicie este environment “WebSQL”, ele reduziu para 685,79, pois foi criado com containers “small” e o peer comercial externo deduz 2,10 GoodWills por cada hora de container small.

Este foi o último teste com o Subutai. Como mencionei na primeira parte, será interessante poder fazer tudo isso dentro do Blockchain Router. Apesar disso, irei adiante com outros laboratórios usando meus próprios peers para testar mais o produto “Blockchain-in-a-Box”.

 

Conclusão

O Subutai é uma plataforma de computação em nuvem distribuída, muito concisa e robusta. Gostei bastante de usá-la, disparar a criação de containers, através de “templates” e “products”, ter uma plataforma de mineração de criptomoedas disponível para uso através do Mist e Ethereum, bem como uma interface gráfica limpa e responsiva.

Como é totalmente open source, está disponível a qualquer pessoa. Você pode começar a trabalhar com ele imediatamente. Aprenda sobre Containers LXC, experimente o Bazaar, implante o PeerOS em VMs ou em servidores bare metal. Todos os recursos computacionais desprezados podem virar minas de dinheiro. Você decide como (gratuito ou pago) e quais recursos você disponibilizará para a plataforma.

Para saber mais (em Inglês):

• Documentação Oficial Subutai: https://docs.subutai.io/;
• Subutai REST API. https://docs.subutai.io/Projects/agent/Private-REST-API.html;
• Mist: https://github.com/ethereum/mist;
• Geth (Nó Ethereum): https://github.com/ethereum/go-ethereum/wiki/geth;
• Blockchain in a Box: https://github.com/subutai-blueprints/blockchain-in-a-box;
• White Paper da Cisco sobre  Fog Computing: http://bit.ly/Cisco_Fog_Computing;
• Open Fog Consortium: https://www.openfogconsortium.org/.

Um abraço e até a próxima!