IBM Cloud Private: Arquitetura Detalhada de Componentes - Revision history

Ebasso at 13:08, 17 January 2019

2019-01-17T13:08:03Z

← Older revision		Revision as of 13:08, 17 January 2019
Line 1:		Line 1:

	[[Ficheiro:Icp arch components.jpg]]		[[Ficheiro:Icp arch components.jpg]]

			[https://www.ibm.com/support/knowledgecenter/en/SSBS6K_3.1.0/getting_started/components.html Lista Completa de Componentes]

	=Kubernetes Core=		=Kubernetes Core=

Ebasso: /* Persistent Storage */

2019-01-16T17:17:47Z

Persistent Storage

← Older revision		Revision as of 17:17, 16 January 2019
Line 171:		Line 171:
	Se você está acostumado com a terminologia usada na documentação do Kubernetes, a terminologia do IBM Cloud Private é um pouco diferente. Em Kubernetes a:		Se você está acostumado com a terminologia usada na documentação do Kubernetes, a terminologia do IBM Cloud Private é um pouco diferente. Em Kubernetes a:

	: '''PersistentVolume''' (PV) é uma definição de armazenamento disponível para todo o cluster		:* '''PersistentVolume''' (PV) é uma definição de armazenamento disponível para todo o cluster
	: '''PersistentVolumeClaim''' (PVC) é a reivindicação de um aplicativo específico para alguns desses armazenamentos.		:* '''PersistentVolumeClaim''' (PVC) é a reivindicação de um aplicativo específico para alguns desses armazenamentos.

	No IBM Cloud Private, o equivalente a um:		No IBM Cloud Private, o equivalente a um:

	: PV é "'''Storage'''", que está disponível para todo o cluster		:* PV é "'''Storage'''", que está disponível para todo o cluster
	: PVC é um “'''Volume'''” que é usado por um aplicativo para armazenar dados		:* PVC é um “'''Volume'''” que é usado por um aplicativo para armazenar dados

	[[Ficheiro:PersistentStorage.png]]		[[Ficheiro:PersistentStorage.png]]

Ebasso: /* Persistent Storage */

2019-01-16T17:17:07Z

Persistent Storage

← Older revision		Revision as of 17:17, 16 January 2019
Line 164:		Line 164:

	=Persistent Storage=		=Persistent Storage=

			Tradicionalmente, os contêineres deveriam ser sem estado, onde o armazenamento existia apenas dentro desse contêiner, isto é, se o contêiner finalizar, as configurações ou dados que existiam nesse contêiner eram perdidas.

			Algumas aplicações entretanto precisam armazenar algum tipo de dado ou estado, portanto, uma solução de armazenamento persistente.

			Se você está acostumado com a terminologia usada na documentação do Kubernetes, a terminologia do IBM Cloud Private é um pouco diferente. Em Kubernetes a:

			: '''PersistentVolume''' (PV) é uma definição de armazenamento disponível para todo o cluster
			: '''PersistentVolumeClaim''' (PVC) é a reivindicação de um aplicativo específico para alguns desses armazenamentos.

			No IBM Cloud Private, o equivalente a um:

			: PV é "'''Storage'''", que está disponível para todo o cluster
			: PVC é um “'''Volume'''” que é usado por um aplicativo para armazenar dados

			[[Ficheiro:PersistentStorage.png]]

			O ICP está focado em fornecer suporte para o seguinte:

			* HostPath
			* NFS
			* GlusterFS and Heketi (api server)
			* vSphereVolume

	= Ver também =		= Ver também =

Ebasso: /* Logging e Monitoração */

2019-01-16T14:33:27Z

Logging e Monitoração

← Older revision		Revision as of 14:33, 16 January 2019
Line 144:		Line 144:

	O método de registro mais fácil e mais abrangente para aplicativos contêinerizados é escrever o standard-error e standard-out e isso é precisamente o que é feito padrão dentro do ICP. O ICP usa uma [[DevOps#ELK_Stack\|ELK Stack]] para tratar logs do sistema.		O método de registro mais fácil e mais abrangente para aplicativos contêinerizados é escrever o standard-error e standard-out e isso é precisamente o que é feito padrão dentro do ICP. O ICP usa uma [[DevOps#ELK_Stack\|ELK Stack]] para tratar logs do sistema.

			Você também pode ver os componentes usando a interface de linha de comando:

			kubectl get configmap --namespace=kube-system \| grep "alert\\|monitor"

	==Como funciona?==		==Como funciona?==

Ebasso: /* Coletando os logs */

2019-01-16T14:29:49Z

Coletando os logs

← Older revision		Revision as of 14:29, 16 January 2019
Line 155:		Line 155:
	== Coletando os logs==		== Coletando os logs==

	* A abordagem mais simples, a aplicação envia logs no stderr e no stdout, que são coletados automaticamente pelo Docker e enviados para o serviço de log IBM Cloud Private por padrão.		A abordagem mais simples, a aplicação envia logs no stderr e no stdout, que são coletados automaticamente pelo Docker e enviados para o serviço de log IBM Cloud Private por padrão. Docker armazena em um arquivo de log separado para esse contêiner (geralmente em /var/lib/docker/containers/<container_id>).
	* A segunda abordagem, empacotando um contêiner Filebeat como um sidecar, é mais envolvido, mas flexível o suficiente para se adaptar à maioria das cargas de trabalho que gravam seus logs em um ou mais arquivos de log.
			A segunda abordagem, empacotando um contêiner Filebeat como um sidecar, é mais envolvido, mas flexível o suficiente para se adaptar à maioria das cargas de trabalho que gravam seus logs em um ou mais arquivos de log. A maioria dos aplicativos armazena logs localmente em arquivos discretos. No Linux, eles geralmente são armazenados em algum lugar no diretório /var/log. A solução mais eficaz é adicionar outro contêiner ao seu pod, geralmente denominado '''sidecar''', que tem visibilidade desses logs e executa uma ferramenta de streaming, como o Filebeat.

	=Persistent Storage=		=Persistent Storage=

Ebasso: /* Como funciona?= */

2019-01-16T14:17:02Z

Como funciona?=

← Older revision		Revision as of 14:17, 16 January 2019
Line 145:		Line 145:
	O método de registro mais fácil e mais abrangente para aplicativos contêinerizados é escrever o standard-error e standard-out e isso é precisamente o que é feito padrão dentro do ICP. O ICP usa uma [[DevOps#ELK_Stack\|ELK Stack]] para tratar logs do sistema.		O método de registro mais fácil e mais abrangente para aplicativos contêinerizados é escrever o standard-error e standard-out e isso é precisamente o que é feito padrão dentro do ICP. O ICP usa uma [[DevOps#ELK_Stack\|ELK Stack]] para tratar logs do sistema.

	==Como funciona?===		==Como funciona?==

	* O IBM Cloud Private Dashboard mostra o status e as métricas para as workloads e o ambiente.		* O IBM Cloud Private Dashboard mostra o status e as métricas para as workloads e o ambiente.

Ebasso: /* Logging e Monitoração */

2019-01-16T14:14:39Z

Logging e Monitoração

← Older revision		Revision as of 14:14, 16 January 2019
Line 144:		Line 144:

	O método de registro mais fácil e mais abrangente para aplicativos contêinerizados é escrever o standard-error e standard-out e isso é precisamente o que é feito padrão dentro do ICP. O ICP usa uma [[DevOps#ELK_Stack\|ELK Stack]] para tratar logs do sistema.		O método de registro mais fácil e mais abrangente para aplicativos contêinerizados é escrever o standard-error e standard-out e isso é precisamente o que é feito padrão dentro do ICP. O ICP usa uma [[DevOps#ELK_Stack\|ELK Stack]] para tratar logs do sistema.

			==Como funciona?===

			* O IBM Cloud Private Dashboard mostra o status e as métricas para as workloads e o ambiente.
			* Elastic Stack coleta logs de todos os nós (master and workers) e workloads.
			* Prometheus coleta métricas.
			* Kibana e o Grafana fornecem visibilidade dos dados coletados.
			* O Prometheus pode ser configurado para enviar alertas para fontes externas. Fontes de exemplo são email e webhooks.

			== Coletando os logs==

			* A abordagem mais simples, a aplicação envia logs no stderr e no stdout, que são coletados automaticamente pelo Docker e enviados para o serviço de log IBM Cloud Private por padrão.
			* A segunda abordagem, empacotando um contêiner Filebeat como um sidecar, é mais envolvido, mas flexível o suficiente para se adaptar à maioria das cargas de trabalho que gravam seus logs em um ou mais arquivos de log.

	=Persistent Storage=		=Persistent Storage=

Ebasso: /* Logging e Monitoração */

2019-01-16T13:52:39Z

Logging e Monitoração

← Older revision		Revision as of 13:52, 16 January 2019
Line 138:		Line 138:

	=Logging e Monitoração=		=Logging e Monitoração=

			O monitoramento de uma implementação do IBM Cloud Private é ativado no momento da instalação e as principais métricas são coletadas imediatamente. O Grafana é utilizado para fornecer o dashboard das métricas coletadas pela Prometheus.

			O ICP vem com Cloud Service Management and Operations (CSMO) Dashboards para ajudar uma organização a obter uma compreensão imediata da integridade de suas implantações do IBM Cloud Private.

			O método de registro mais fácil e mais abrangente para aplicativos contêinerizados é escrever o standard-error e standard-out e isso é precisamente o que é feito padrão dentro do ICP. O ICP usa uma [[DevOps#ELK_Stack\|ELK Stack]] para tratar logs do sistema.

	=Persistent Storage=		=Persistent Storage=

Ebasso: /* kubectl */

2019-01-16T13:25:16Z

kubectl

← Older revision		Revision as of 13:25, 16 January 2019
Line 110:		Line 110:

	: A interface de linha de comando do Kubernetes.		: A interface de linha de comando do Kubernetes.


			=Application Center=

			: O Application Center fornece um local centralizado a partir do qual você pode procurar e instalar pacotes em seu cluster. Esses pacotes são representados pelos gráficos de Helm abaixo.

			[[Ficheiro:Helm packages.png]]

			Com o Helm, você pode fornecer rapidamente o acesso controlado pelo usuário para implantar mais do que aplicativos elementares baseados em pods em seu ambiente Kubernetes.

			==Helm Repository==

			: O Helm Repository é um repositório para manter os Helm charts.

			==Tiller (Server)==

			: O Tiller é usado dentro do cluster, gerenciando as diferentes instalações ou lançamentos de seus charts.

			=IBM Cloud Private Catalog=
			:
			O IBM Cloud Private Catalog É uma coleção de pacotes de implantação (Helm charts ) exibidos como blocos que fornecem acesso a diversos softwares, e fornece acesso simples e de autoatendimento ao software IBM e Open Source criado para o Kubernetes.

			Por padrão, 2 repositórios estão incluídos:

			:* IBM Charts – disponíveis publicamente no github.com/ibm/charts
			:* Local Charts – Instalados com o IBM Cloud Private

			=Logging e Monitoração=

			=Persistent Storage=

	= Ver também =		= Ver também =

Ebasso: /* MariaDb */

2019-01-16T13:06:44Z

MariaDb

← Older revision		Revision as of 13:06, 16 January 2019
Line 92:		Line 92:

	: Um banco de dados relacional de código aberto feito pelos desenvolvedores originais do MySQL. Nesse caso, ele é usado para fazer back-end do Keystone.		: Um banco de dados relacional de código aberto feito pelos desenvolvedores originais do MySQL. Nesse caso, ele é usado para fazer back-end do Keystone.

			=Image Management=

			: Um cenário típico com o IBM Cloud Private ou com o Kubernetes é que um desenvolvedor baixe uma imagem de um registro público, faça testes e alterações, e em seguida fará um push dessa imagem em seu registro privado local. Nesse ponto, essa imagem fica disponível para uso nos diversos cluster da sua organização.

			=Interfaces para o Usuário=

			==Cluster Management Console==

			: O Cluster Management Console é a GUI do IBM Cloud Private que é usada para gerenciar, monitorar e solucionar problemas de seus aplicativos e cluster a partir de um console de gerenciamento único, centralizado e seguro.

			==Kubernetes Web UI==

			: Você pode usar também a interface da Web do Kubernetes para gerenciar o IBM Cloud Private.

			==kubectl==

			: A interface de linha de comando do Kubernetes.

	= Ver também =		= Ver também =