Cloud: Conceitos importantes para usuários do IBM Bluemix

From Wiki
Revision as of 20:12, 29 May 2017 by Ebasso (talk | contribs) (→‎Domains e Routes)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Abaixo temos alguns conceitos importantes para quem tem uma conta no IBM Bluemix

Conceitos

Cloud Foundry

O Cloud Foundry é uma ambiente de execução (Runtime), onde sua aplicação vai ser executada. Você não precisa se preocupar em qual Sistema
Operacional, Memória, ..., o você seleciona um Runtime do Catálogo, e a sua aplicação será executada. Se você fizer um deploy de uma aplicação Java, : o Runtime terá uma JVM, Application Server, ... para que sua aplicação seja executada.
https://www.cloudfoundry.org/

Organização do Bluemix

Organization

Organization é uma entidade que abrange todos os recursos de uma conta pública no Bluemix.

De forma semelhante a uma empresa, associação, ... que estarão disponibilizando uma aplicação no Bluemix.

Você acessa através do menu Manage -> Account -> Organizations

Ficheiro:BluemixOrgUsers.png

Users

São os Usuário na organização, que compartilham os recursos das sua conta, e que podem funções específicas por Organization e Space.

Outro conceito é o de Colaborador e Membro.

  • Colaborador
Se você tem uma conta no Bluemix e alguém te convida você para uma organização, você será um colaborador.
  • Membro
Se você não tem uma conta no Bluemix, mas alguém te convida você para uma organização, você será um membro.

Quota

Quota define os recursos disponíveis para a sua organização, isto é, a quantidade de serviços e de memória alocado pra sua organização.

Exemplo: Um usuário X pode criar uma VM com no máximo 2 processadores e no máximo 4 GB de RAM.

Space

Space é um grupo lógico de aplicações e serviços na plataforma. Podem haver múltiplos espaços por organização.

Usuários de uma organização podem ser associados a múltiplos espaços e terem diferentes papéis (Developer, Manager ou Auditor) por espaço. Mas somente usuários com o papel de Developer, pode criar aplicações e adicionar serviços a um espaço. Como:

  • Administrador
  • Desenvolvedor
  • Auditor

Exemplo: Criar um projeto com os serviços e pessoas envolvidas com um software de RH, exemplo:

  • RHDigital-dev
  • RHDigital-hom
  • RHDigital-producao

Region

Region é um datacenter on a Bluemix pública está localizada.

Selecione uma região mais próxima do seu cliente para fazer o deploy de suas aplicações, com isso você diminui a latência de rede.

Outro motivo para usar uma região, é caso seu cliente tenha questões legais que regulamente onde deve ficar os seus dados.

Tabela de Regiões e API endpoints.

Domains e Routes

Domain é o domínio internet para acessar sua aplicação e está associado à sua organização. Exemplo: mybluemix.net

Route é a URL que utilizada para direcionar requisições para uma aplicação. Basta acessar o Dashboard para ver a rota.

API endipoint

API endipoint é uma url na REGION, onde existe um datacenter do Bluemix.
Exemplos:
* for Dallas, US region is https://api.ng.bluemix.net
* for London, UK region is https://api.eu-gb.bluemix.net
* for Sydney, Australia region is https://api.au-syd.bluemix.net

Paas no Bluemix

Runtimes

Um runtime é conjunto de recursos para executar uma aplicação. Exemplos de runtime: uma plataforma Nodejs, um compilador Python, uma Java Virtual Machine (JVM).

Boilerplates

Um Boilerplate consiste na combinação de um runtime e serviços pré-definidos. Por exemplo: o boilerplate "NodeJs Cloudant DB Web Start", disponibiliza um runtime com NodeJs e um banco de dados NoSQL (Cloudant) já configurado e um aplicação tipo Hello World!.

Buildpack

Buildpack é uma coleção de scripts que prepara seu código para ser executado no Paas. Um buildpack coleta dependências de um runtime e do framework de uma aplicação, então ele empacota estas dependências em um droplet que pode ser deployed no cloud.

Service

Um serviço prove uma funcionalidade pronta para o uso por sua aplicação. Exemplos de serviços podem ser um banco de dados, messaging, push notifications, elastic cache.

Existem 2 tipos de serviço:

  • Managed service
Integrados no Bluemix/Cloud Foundry através de um broker de serviços que implementam uma Service Broker API. Esta api notifica o Catalogo
de serviços do Bluemix/Cloud Foundry com 4 funções: create, delete, bind ou unbind. O broker então passa essas chamadas para o serviço propriamente.
Desta maneira os usuários podem criar instâncias dos serviços e credenciais conforme a demanda.
  • User provided service
As instâncias de serviço fornecidas pelo usuário são um mecanismo para fornecer credenciais a aplicativos para instâncias de serviço que foram
pré-provisionadas fora do Bluemix.

Bluemix e Cloud Foundry

IBM Bluemix PaaS is built on Cloud Foundry, so you should understand the Bluemix and Cloud Foundry internal architecture and its components, such as Diego Cell, Cloud Controller, the Router and the interactions to maintain application availability.

Cloud Foundry Components http://docs.cloudfoundry.org/concepts/architecture/

Diego Cell

The Diego Cell hosts application instances, reports application status to the Diego Bulletin Board Service (BBS), and provides application logs, errors, and metrics to the Loggregator. Application instances live inside Garden containers. Containerization ensures that application instances run in isolation, get their fair share of resources, and are protected from noisy neighbors.

Cloud Controller

The Cloud Controller directs the deployment of applications. When you push an application to Cloud Foundry, the Cloud Controller uses the CC-Bridge to store the application bits and direct the Diego Brain to coordinate Diego Cells to stage and run applications. Router

The Router routes incoming traffic to the appropriate component in the environment. For example, the Router sends traffic to the Cloud Controller for management of applications in their lifecycle or a hosted application on a Diego Cell. The Router is informed of active application instances through the router-emitter that monitors status in the Diego Bulletin Board Service (BBS).

Application Availability

Application availability is coordinated by the CC-Bridge nsync component, the Bulletin Board Service (BBS), and the Cell Rep component. The Cloud Controller uses the nsync component to save the number of instances for an application into a Desired Long Range Process (DesiredLRP) structure in the BBS database. The Cell Rep monitors containers and provides the Actual Long Range Process (ActualLRP) count to the BBS. The BBS uses its convergence process to monitor the DesiredLRP and ActualLRP values and launches or kills application instances to ensure the ActualLRP matches the DesiredLRP count.

Service Broker

The service broker advertises a catalog of service offerings and service plans to Bluemix and Cloud Foundry, and receives calls from Cloud Foundry for four functions: create, delete, bind, and unbind. The broker then passes these calls to the service itself.

Links

IBM Bluemix documentation: “Virtual machines”

https://www.ng.bluemix.net/docs/virtualmachines/vm_index.html

IBM Bluemix documentation: “IBM Containers”

https://www.ng.bluemix.net/docs/containers/container_index.html

Ver também