Author Archives: Luis Fernando Chaim

Spring Boot Kubernetes

Spring Boot Kubernetes

This guide walks you through the process of deploying a Spring Boot application on Kubernetes. There are many choices of how to do things with Spring Boot and Kubernetes — the intention with this guide is to get you up and running as quickly as possible, not to discuss all the alternatives or go into all the details of how you get to production (which is, of course, our favourite place to be).

There are some interactive tutorials that complement and extend the content of this guide on Katacoda/springguides. If you follow those tutorials, all the code will be running in the cloud from your browser. Or you can create your own cluster and install all the tools you need locally, then copy paste from the guides.Getting Started with Spring Boot on Kubernetes: the same material as this guide, but running in your browser.Install Kubernetes: a guide to installing Kubernetes locally using Kind. You can use this to get setup on your laptop if you prefer to run the tutorials there.Kubernetes Probes with Spring Boot: a guide to liveness and readiness probes with Spring Boot.

What you’ll build

Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. It groups containers that make up an application into logical units for easy management and discovery. In this guide we will build and deploy a simple Spring boot application.

There is also a Getting Started Guide and a Topical Guide on Docker, which cover some of the background on building a container image.

What you’ll need

You will need a Linux or Linux-like command line. Command line examples in this guide work on Linux, a MacOS terminal with a shell, or WSL on Windows.

You will also need a Kubernetes cluster and the command line tool Kubectl. You can create a cluster locally using Kind (on Docker) or Minikube. Or you can use a cloud provider, such as Google Cloud PlatformAmazon Web Services or Microsoft Azure. Before proceeding further, verify you can run kubectl commands from the shell. E.g. (using kind):

$ kubectl cluster-info
Kubernetes master is running at https://127.0.0.1:46253
KubeDNS is running at https://127.0.0.1:46253/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

and

$ kubectl get all
NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.43.0.1    <none>        443/TCP   7m13s

Create a Spring Boot Application

The first thing we will do is create a Spring Boot application. If you have one you prefer to use already in github, you could clone it in the terminal (git and java are installed already). Or you can create an application from scratch using start.spring.io:

curl https://start.spring.io/starter.tgz -d dependencies=webflux,actuator | tar -xzvf -

You can then build the application:

./mvnw install
It will take a couple of minutes the first time, but then once the dependencies are all cached it will be fast.

And you can see the result of the build. If the build was successful, you should see a JAR file, something like this:

ls -l target/*.jar
-rw-r--r-- 1 root root 19463334 Nov 15 11:54 target/demo-0.0.1-SNAPSHOT.jar

The JAR is executable:

$ java -jar target/*.jar

The app has some built in HTTP endpoints by virtue of the “actuator” dependency we added when we downloaded the project. So you will see something like this in the logs on startup:

...
2019-11-15 12:12:35.333  INFO 13912 --- [           main] o.s.b.a.e.web.EndpointLinksResolver      : Exposing 2 endpoint(s) beneath base path '/actuator'
2019-11-15 12:12:36.448  INFO 13912 --- [           main] o.s.b.web.embedded.netty.NettyWebServer  : Netty started on port(s): 8080
...

So you can curl the endpoints in another terminal:

$ curl localhost:8080/actuator | jq .
{
  "_links": {
    "self": {
      "href": "http://localhost:8080/actuator",
      "templated": false
    },
    "health-path": {
      "href": "http://localhost:8080/actuator/health/{*path}",
      "templated": true
    },
    "health": {
      "href": "http://localhost:8080/actuator/health",
      "templated": false
    },
    "info": {
      "href": "http://localhost:8080/actuator/info",
      "templated": false
    }
  }
}

To complete this step, send Ctrl+C to kill the application.

Containerize the Application

There are multiple options for containerizing a Spring Boot application. For local development and testing it makes sense to start with a Dockerfile as the docker build workflow is generally well known and understood.

If you don’t have docker locally or want to automatically push an image to a registry then Jib would be a good choice. In an enterprise setting, when you need a trusted build service for a CI/CD pipeline, you could look at Cloud Native Buildpacks.

First create a Dockerfile:

FROM openjdk:8-jdk-alpine AS builder
WORKDIR target/dependency
ARG APPJAR=target/*.jar
COPY ${APPJAR} app.jar
RUN jar -xf ./app.jar

FROM openjdk:8-jre-alpine
VOLUME /tmp
ARG DEPENDENCY=target/dependency
COPY --from=builder ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY --from=builder ${DEPENDENCY}/META-INF /app/META-INF
COPY --from=builder ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT ["java","-cp","app:app/lib/*","com.example.demo.DemoApplication"]

Then build the container image, giving it a tag (choose your own ID instead of “springguides” if you are going to push to Dockerhub):

$ docker build -t springguides/demo .

You can run the container locally:

$ docker run -p 8080:8080 springguides/demo

and check that it works in another terminal:

$ curl localhost:8080/actuator/health

Finish off by killing the container.

You won’t be able to push the image unless you authenticate with Dockerhub (docker login), but there’s an image there already that should work. If you were authenticated you could:

$ docker push springguides/demo

In real life the image needs to be pushed to Dockerhub (or some other accessible repository) because Kubernetes pulls the image from inside its Kubelets (nodes), which are not in general connected to the local docker daemon. For the purposes of this scenario you can omit the push and just use the image that is already there.

Just for testing, there are workarounds that make docker push work with an insecure local registry, for instance, but that is out of scope for this scenario.

Deploy the Application to Kubernetes

You have a container that runs and exposes port 8080, so all you need to make Kubernetes run it is some YAML. To avoid having to look at or edit YAML, for now, you can ask kubectl to generate it for you. The only thing that might vary here is the --image name. If you deployed your container to your own repository, use its tag instead of this one:

$ kubectl create deployment demo --image=springguides/demo --dry-run -o=yaml > deployment.yaml
$ echo --- >> deployment.yaml
$ kubectl create service clusterip demo --tcp=8080:8080 --dry-run -o=yaml >> deployment.yaml

You can take the YAML generated above and edit it if you like, or you can just apply it:

$ kubectl apply -f deployment.yaml
deployment.apps/demo created
service/demo created

Check that the application is running:

$ kubectl get all
NAME                             READY     STATUS      RESTARTS   AGE
pod/demo-658b7f4997-qfw9l        1/1       Running     0          146m

NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
service/kubernetes   ClusterIP   10.43.0.1       <none>        443/TCP    2d18h
service/demo         ClusterIP   10.43.138.213   <none>        8080/TCP   21h

NAME                   READY     UP-TO-DATE   AVAILABLE   AGE
deployment.apps/demo   1/1       1            1           21h

NAME                              DESIRED   CURRENT   READY     AGE
replicaset.apps/demo-658b7f4997   1         1         1         21h
d
Keep doing kubectl get all until the demo pod shows its status as “Running”.

Now you need to be able to connect to the application, which you have exposed as a Service in Kubernetes. One way to do that, which works great at development time, is to create an SSH tunnel:

$ kubectl port-forward svc/demo 8080:8080

then you can verify that the app is running in another terminal:

$ curl localhost:8080/actuator/health
{"status":"UP"}

Source: https://spring.io/guides/gs/spring-boot-kubernetes/

Canais de treino no Youtube

Este post ajudará com a busca de canais de treino, via Youtube.

Fitness Blender
https://www.youtube.com/channel/UCiP6wD_tYlYLYh3agzbByWQ

Blogilates
https://www.youtube.com/channel/UCIJwWYOfsCfz6PjxbONYXSg

Lu Oliveira
https://www.youtube.com/user/LuOliveiraTrainer/videos

Exercício em Casa
https://www.youtube.com/channel/UCn12e0roN5zHc0akyskTF6A

Gymvirtual
https://www.youtube.com/user/gymvirtual

BeFit
https://www.youtube.com/user/BeFit

Dance Fitness whit Jessica
https://www.youtube.com/user/FitnesswithJessica

P4P Brasil
https://www.youtube.com/user/P4Pbrasil

Home Fit Home
https://www.youtube.com/channel/UCrKsRYqWGaqmJon7lFyz3yg

4FitClub
https://www.youtube.com/user/4FitClub

Ketty Sato
https://www.youtube.com/user/34516331/videos

Mock JSON Generator

Este post apresenta o conceito de Mock e JSON Generator.

Conceito

Mock

Objetos Mock, objetos simulados ou simplesmente Mock (do inglês Mock object) em desenvolvimento de software são objetos que simulam o comportamento de objetos reais de forma controlada. São normalmente criados para testar o comportamento de outros objetos. Em outras palavras, os objetos mock são objetos “falsos” que simulam o comportamento de uma classe ou objeto “real” para que possamos focar o teste na unidade a ser testada.

JSON

JSON (JavaScript Object Notation – Notação de Objetos JavaScript) é uma formatação leve de troca de dados. Para seres humanos, é fácil de ler e escrever. Para máquinas, é fácil de interpretar e gerar. Está baseado em um subconjunto da linguagem de programação JavaScript, Standard ECMA-262 3a Edição -Dezembro – 1999.

Generator

No contexto de TI, generator é uma implementação que tem o objetivo de gerar algum objeto, código ou estrutura de dados, de forma randômica, rápida e escalável.

Soluções

JSON Generator

Fonte: https://www.json-generator.com/

Gere todos os dados aleatórios que você quiser com o poder dos modelos ágeis e salve-os em nossos servidores para uso posterior.

Mockaroo

Fonte: https://mockaroo.com/

 

Arquitetura de micro-serviços

A arquitetura de micro-serviços pode trazer muitos benefícios para o desenvolvimento de software. Seus principais pontos fortes são a escalabilidade, a resiliência da aplicação, facilidade de implantação e aumento na eficiência da manutenção dos sistemas.

Nesse artigo, vamos entender um pouco melhor sobre a organização de um micro-serviço e as camadas o compõe, definindo o seu ecossistema e explicando como cada parte se relaciona entre si.

O ecossistema da arquitetura de microsserviços

Construir, padronizar e manter a infraestrutura de uma maneira estável, escalável, tolerante a falhas e confiável é essencial para o sucesso das operações de um micro-serviço .

Existem vários modelos distintos que sugerem como um ecossistema de micro-serviços deve ser organizado. Um modelo interessante e bem estruturado é o descrito por Susan J. Fowler, em seu livro intitulado “Production-Ready Microservices”.

Segunda ela, o ecossistema de micro-serviços pode ser dividido em quatro “camadas”, sendo elas: Hardware, comunicação, plataforma de aplicações e micro-serviços.

Apesar das camadas estarem todas interligadas, estabelecer essa divisão nos ajuda a entender melhor as diferentes responsabilidades e os diferentes módulos que compõem um ecossistema da arquitetura de micro-serviços.

Hardware

Hardware são os computadores e equipamentos onde os micro-serviços são armazenados e executados. Estes servidores podem estar dentro da empresa, ou pertencerem a provedores de infraestrutura em nuvem, como Amazon Web Services, Google Cloud Platform ou Windows Azure.

Existem algumas soluções que visam diminuir a dificuldade de se gerenciar estes equipamentos, como o emprego de tecnologias de conteinerização e clusterização para o armazenamento dos micro-serviços.

É importante que os servidores sejam providos de mecanismos de monitoramento e logging para identificar problemas de falhas de disco, rede ou processamento, por exemplo. Em um ecossistema de grande diversidade e dinamismo, é importante ter à disposição ferramentas que evidenciem dados da saúde das máquinas onde esses micro-serviços operam e mantenham um histórico destas informações. Desta maneira, eventuais problemas podem ser rapidamente identificados e resolvidos, uma vez que são facilmente detectados e rastreados. Adicionalmente, um mecanismo de monitoramento bem estruturado permite que seja possível acompanhar o impacto que a evolução das aplicações provoca na infraestrutura como um todo.

Comunicação

A Comunicação engloba todo o conjunto responsável por permitir que a interação entre micro-serviços ocorra, e é composta por elementos chave como os endpoints de APIService Discovery e Service Registry, e Load Balancers.

Endpoints de API

Dado uma API de um micro-serviço, seus endpoints são os pontos através dos quais toda a comunicação externa acontece. É nos endpoints que o micro-serviço envia e recebe informações de outros micro-serviços ou aplicações.

Service Discovery e Service Registry

Em um ecossistema de micro-serviços executados em nuvem, as configurações de rede mudam dinamicamente dadas suas características de escalabilidade, falhas e atualizações.  Diante deste cenário dinâmico, é necessário um mecanismo que mantenha a localização mais recente e atualizada de cada serviço.  Os micro-serviços registram a si mesmos no registrador de serviços quando são instanciados, e removidos quando são encerrados ou quando apresentam alguma falha.

Quando um serviço precisa se comunicar com outro, ele recorre ao Service Discovery, em busca da localização mais atualizada deste serviço. Este gerenciamento é um ponto importante e demanda muita atenção na configuração de um ecossistema de micro-serviços.

Load Balancer

Os balanceadores de carga são os responsáveis por rotear as requisições vindas dos clientes para as instâncias do micro-serviço requisitado, garantindo que nenhum servidor seja sobrecarregado e maximizando sua velocidade e capacidade. Se a instância de um determinado micro-serviço cair, o balanceador de carga para de rotear requisições de clientes para esta instância. Similarmente, quando uma nova instância fica disponível o balanceador começa a repassar requisições para ela automaticamente.

Plataforma de aplicações

A Plataforma de aplicações é a terceira camada, e engloba todas as ferramentas que são independentes de um micro-serviço. Estas ferramentas devem ser construídas e dispostas de maneira que o time de desenvolvimento não tenha que se preocupar com nada além da lógica de sua própria aplicação.

Padrões nos processos de desenvolvimento com uso de repositórios de código como GitHub e Bitbucket, por exemplo, e mirroring de ambiente de produção são eficientes para manter a base de código organizada, e simular todas as dependências que a aplicação terá quando for ao ar.

Builds centralizados e automatizados com integração e deploys contínuos são essenciais. Dependendo do tamanho de sua aplicação e do número de micro-serviços que ela possui, dezenas de deploys podem ocorrer diariamente. Por isso, é importante que as ferramentas sejam corretamente configuradas, e que sejam capazes de executar testes automaticamente, adicionar novas dependências conforme necessário, e preparar os releases a medida que novas versões são codificadas.

Por último, ter um mecanismo de log centralizado e monitoramento a nível de micro-serviço é crucial para entender eventuais problemas que ocorrem no serviço implementado. Dado que a natureza de micro serviços é de sofrer alterações constantemente, os logs permitem entender o que aconteceu no sistema em um momento específico. O monitoramento, por sua vez, é utilizado para verificar a saúde e status de um serviço em tempo real.

Micro-serviços

Os micro-serviços concentram a lógica para resolver o problema para o qual se propõe. A ideia é que o serviço seja totalmente abstraído dos demais componentes explicados acima, sem contato com as especificidades de hardware, service registry e service discovery, balanceamento de carga e processos de deploy, por exemplo. O micro-serviço em si consiste apenas do código e configurações específicas que devem ser aplicadas sobre ele para que possa entregar as funcionalidades para qual foi idealizado.

De maneira geral, este é um modelo de ecossistema da arquitetura de micro-serviços. Para serem aplicados em projetos reais, os tópicos citados devem ser estudados e compreendidos mais a fundo, tendo sempre em mente que esse tipo de arquitetura possui componentes muito dinâmicos, e que estão em constante aprimoramento.

Image API

Este post demonstra o conceito da API de tratamento de imagem, publicada no Github.

Introdução

Este projeto foi desenvolvido utilizando Spring Boot, Swagger e REST.

Spring Boot

Spring Boot é um projeto da Spring que veio para facilitar o processo de configuração e publicação de nossas aplicações. Você escolhe os módulos que deseja através dos starters que inclui no pom.xml do seu projeto. Eles, basicamente, são dependências que agrupam outras dependências.

Swagger

O Swagger é um dos frameworks mais usados para se documentar API’s REST. Ele facilita para que os clientes que consomem nossas API’s saibam quais os parâmetros nossas operações recebem, qual o retorno, o modelo, o media type retornado JSON, XML, CSV, binário etc. Sendo assim os clientes não precisam necessariamente discutir com a equipe de desenvolvimento da APIsobre como usá-la.

REST

REST é acrônimo de Representational State Transfer, e tem como objetivo primário a definição de características fundamentais para a construção de aplicações Web seguindo boas práticas.

Veja o post sobre boas práticas REST (http://whs.com.br/dicas/rest-boas-praticas)

Github

https://github.com/lfchaim/image-api

Swagger UI

Para visualizar o Swagger da aplicação, devemos iniciar através da classe ImageApiApplication.

Depois de iniciar, pode-se acessar através do endereço:

http://localhost:8080/swagger-ui.html

Postman

O Postman é uma ferramenta que tem como objetivo testar serviços RESTful (Web APIs) por meio do envio de requisições HTTP e da análise do seu retorno. Com ele é possível consumir facilmente serviços locais e na internet, enviando dados e efetuando testes sobre as respostas das requisições.

Instale o Postman e importe o Collection para efetuar os testes. O download pode ser feito aqui.

https://github.com/lfchaim/image-api/blob/master/postman/ImageAPI.postman_collection.json

 

REST – Boas Práticas

Este post visa apresentar as boas práticas na implementação de serviços REST.

REST – Conceito

REST (Representational State Transfer) é um modelo arquitetural que foi apresentado em uma tese de doutorado de Roy Fielding, co-autor do protocolo HTTP.

RESTful, existe uma confusão entre os dois termos REST e RESTful, resumidamente REST é o modelo arquitetural e RESTful é um sistema que é capaz de aplicar integralmente os princípios de REST. Mais adiante, veremos exemplos de RESTful.

Nomenclatura de URIs

Para facilitar o uso de sua aplicação REST, é bom utilizar versionamento na URI (também conhecido como endpoint).

Exemplo:

  • http://[DOMINIO]/api/v1 (URI sem contexto e subdomínio)
  • http://[SUBDOMINIO].[DOMINIO]/api/v1 (URI sem contexto e com subdomínio)
  • http://[DOMINIO]/[CONTEXTO/api/v1 (URI com contexto e sem subdominio)
  • http://[SUBDOMINIO].[DOMINIO]/[CONTEXTO]/api/v1 (URI com contexto e com subdomínio)

Recursos da URI

Após a definição de Subdomínio, Contexto e Versão, definimos os recursos de nossa API, geralmente, utilizando identificadores no plural.

Exemplo:

  • /customers
  • /products
  • /invoices

Métodos HTTP

É boa prática utilizar métodos HTTP para identificar as operações permitidas.

Exemplo:

  • GET solicita dados do recurso. Requisições utilizando o Método GET devem retornar apenas dados e não devem produzir nenhuma alteração na base.
  • POST solicita que o servidor crie um recurso no banco de dados.
  • PUT solicita que o servidor atualize o recurso.
  • DELETE solicita que os recursos, ou sua instância, sejam removidos do banco de dados.
  • PATCH solicita que o servidor realize modificações parciais em um recurso.

Cadastrar um documento

[POST] /documents

Buscar todos os documentos

[GET] /documents

Buscar o documento de id 1

[GET] /documents/1

Alterar o documento de id 1

[PATCH] /documents/1

Excluir o documento de id 1

[DELETE] /documents/1

Resposta HTTP

Ao invocar um método, o cliente precisa receber uma resposta sobre a execução do método, se ocorreu tudo bem ou se apresentou erro. Para ajudar a identificar o erro, a API deve utilizar o código HTTP da maneira mais usual de mercado.

Categorias:
2xx (Categoria de sucesso)
Esses códigos de status representam que a ação solicitada foi recebida e processada com sucesso pelo servidor.

200 OK
Código de resposta padrão representando sucesso para o GET, PUT ou POST.

201 Created
Deve ser retornado sempre que uma nova instância for criada.

204 No Content
O servidor processa corretamente a requisição, mas não precisa retornar nenhum conteúdo.

4xx (Categoria de erros causados pelo cliente)
Esses códigos de status representam que solicitação realizada pelo cliente está incorreta.

400 Bad Request
Indica que a solicitação realizada pelo cliente não foi processada, pois o servidor não conseguiu entender o que o ele está solicitando.

401 Unauthorized
Indica que o cliente não tem permissão para acessar recursos e deve solicitar novamente com as credenciais necessárias.

403 Forbidden
Indica que a solicitação é válida e o cliente está autenticado, mas o cliente não tem permissão para acessar a página ou recurso por qualquer motivo. Por exemplo, às vezes, o cliente autorizado não tem permissão para acessar o recurso específico.

404 Not Found
Indica que o servidor não encontrou nada que corresponda à URI solicitada.

5xx (categoria de erro do servidor)
Categoria de erros gerados pelo servidor ao processar a solicitação.

500 Internal Server Error
Indica que a solicitação é válida, mas o servidor encontrou uma condição inesperada que impediu o cumprimento da solicitação.

503 Service Unavailable
Indica que o servidor está inoperante ou indisponível para receber e processar a solicitação. Principalmente se o servidor está em manutenção.

A lista completa de Código HTTP pode ser consultada em https://httpstatuses.com

Filtragem(Filtering)

Para filtrar o conjunto de dados, podemos passar várias opções por meio de parâmetros de consulta.
Por exemplo, GET /pessoas?tipo=pf&localizacao=SC filtraria os dados da lista de pessoas físicas de Santa Catarina.

Pesquisa(Searching)

Ao pesquisar o nome da pessoa na lista de pessoas, o endpoint a ser exporto deve ser do tipo GET = /pessoas?Search=fernando

Paginação(Pagination)

Quando o conjunto de dados é muito grande, dividimos o conjunto de dados em partes menores, o que ajuda a melhorar o desempenho e é mais fácil de lidar com a resposta(controlar itens por página e quantas páginas podem ser mostradas).
Por exemplo: GET /pessoas?Page=23 significa obter a lista de pessoas da 23ª página.
Se adicionar muitos parâmetros de consulta em métodos GET tornar o URI muito longo, o servidor poderá responder com 414 URI Status HTTP muito longo. Nesses casos, params também podem ser passados no corpo da solicitação do método POST.

RESTful

Uma API RESTful significa que ela possui a capacidade de evoluir e ajudar a identificação de métodos relacionados. Por exemplo, no método de consulta de um pedido, podemos incluir no retorno, a URI para consultar os dados do Cliente, facilitando a codificação das aplicação que usam a API.

Exemplo (veja o atributo permalink):

{
   "invoiceNumber": 21564879821,
   "invoiceDate": "2012-10-09 12:00:00 +05:30",
   "customer": {
      "document": "01698798166215",
      "name": "John Baker",
      "permalink": "/v2/customers/3a22b041-8d45-496a-946d-bd2252a0d28c"
   }
}

 

Instalando MySQL 8 no Windows

Este post demonstra a instalação e configuração do MySQL 8 (versão 8.0.16) no Windows, via arquivo zip.

Baixando o MySQL

Acesse o site https://dev.mysql.com/downloads/ e baixe o MySQL Community Server 8.0.16 (Zip Archive).

Descompactando o MySQL

Após baixar o arquivo mysql-8.0.16-winx64.zip, descompacte-o no diretório destino. Para este exemplo, descompactamos em C:\opt\mysql-8.0.16-winx64\

Inicializando o MysQL

Abra um Prompt de Comando e digite:

cd C:\opt\mysql-8.0.16-winx64\bin
C:\opt\mysql-8.0.16-winx64\bin\mysqld --initialize

Subindo o MySQL

Na pasta bin, digite:

C:\opt\mysql-8.0.16-winx64\bin\mysqld --console

Testando conexão

Com o servidor no ar, abra outro Prompt de Comando e digite:

C:\opt\mysql-8.0.16-winx64\bin\mysql -u root -h localhost

Ocorrerá um erro de autenticação, pois não foi enviada a senha. Veja o erro abaixo:

ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

Verificando senha do MySQL

Localize o arquivo com extensão .err (no meu caso o arquivo é Lenovo-I7.err) e abra no editor. Verifique que a senha é apresentada no arquivo.

A temporary password is generated for root@localhost: hjD8X3e8Jq&W

Conectando com a senha

Agora, utilize o comando abaixo, com a senha obtida no arquivo de erro.

C:\opt\mysql-8.0.16-winx64\bin\mysql -u root -h localhost -p

Quando solicitar a senha, informe:

Enter password: hjD8X3e8Jq&W (aparecerá com asteriscos)

Deverá aparecer o prompt com o MySQL conectado

mysql >

Alterando a senha do usuário root

Conectado no MySQL, digite:

mysql> alter user 'root'@'localhost' identified by 'root';
Query OK, 0 rows affected (0.01 sec)

Baixando o servidor

Para baixar o servidor, de forma normal, digite:

C:\opt\mysql-8.0.16-winx64\bin\mysqladmin -u root -p shutdown

Enter password: root

Instalando como serviço

Para instalar o MySQL como serviço do Windows, digite:

C:\opt\mysql-8.0.16-winx64\bin\mysqld --install "MySQL 8.0.16"

Service successfully installed.

NOTA: Importante executar o Prompt de Comando como Administrador!!!

Para verificar o serviço, execute o comando abaixo (na janela que se abrirá, perceba que existe o serviço MySQL 8.0.16:

services.msc

 

Instalando Anaconda no Ubuntu

Este post demonstra a instalação e comandos básicos do Anaconda no Ubuntu.

Baixando o Anaconda

Acesse a URL

https://www.anaconda.com/distribution/

Instalando o Anaconda

Executar o arquivo Anaconda3-2018.12-Linux-x86_64.sh

$ sh Anaconda3-2018.12-Linux-x86_64.sh

A instalação será efetuada na pasta padrão ~/anaconda3

Configurando Path

Para adicionar o caminho dos programas no Path, digite:

$ export PATH=~/anaconda3/bin:$PATH

Atualizando o Conda

$ conda update -n base -c defaults conda

Criando ambiente

Para criar um ambiente, digite:

$ conda create --name myenv

Ativando ambiente

$ source activate myenv

Rodando o Jupyter

$ jupyter notebook

Executando o Anaconda Navigator

O Anaconda Navigator é uma interface gráfica incluída no Anaconda que permite que você inicie aplicativos e gerencie pacotes, ambientes e canais Conda sem a necessidade de usar linha de comando.

$ anaconda-navigator

Docker – Kubernetes – Openshift

Docker

Docker surgiu em 2013 inicialmente como uma camada sobre a funcionalidade do Kernel do Linux chamada LXC (Linux Containers), que permite a execução de processos de maneira isolada e restrita. Posteriormente trocaram a LXC pela libcontainer, permitindo seu uso além do Linux.
A tecnologia de containers possibilita rodar processos, serviços e aplicativos de maneira isolada, ou seja, um não enxerga o outro, e de forma limitada, no qual cada um possui um limite dos recursos de hardware disponíveis como quantidade de memória e espaço em disco.
Containers são mais “leves” do que máquinas virtuais pois não precisam simular o hardware e não precisam carregar um sistema operacional completo antes de executar uma aplicação. Utilizam como base Imagens Docker que são arquivos compactados contendo um sistema de arquivos e a aplicação a ser executada.
Basicamente uma aplicação é empacotada na forma de uma Imagem Docker e cada instância em execução é chamada de container.

Kubernetes

Orquestração de containers é a capacidade de provisionar automaticamente a infraestrutura necessária para atender às solicitações das aplicações web por meio de de containers do Docker.
Kubernetes, também conhecido como k8s, é uma ferramenta open source criada pela Google e distribuída em 2014 para automatização de deploys e gerenciamento de containers. Com ele é possível criar um cluster de containers em clouds privadas ou públicas (AWS, Google Cloud, etc.).
Algumas vantagens do Kubernetes:

  • Container sempre online: verifica a saúde da aplicação e recria o container se identificar alguma anomalia.
  • Autoscaling: obtém métricas e verifica se há necessidade de crescer horizontalmente.
  • Descoberta de Serviço: containers recebem um endereço IP e conseguem enxergar um ao outro por meio de uma rede virtual.
  • Crescimento Horizontal: com um simples comando é possível aumentar o número de containers da mesma imagem.
  • Balanceador de Carga: utiliza load balancer para dividir a carga de requisições recebidas entre os containers.
  • Rollbacks automáticos: se algo der errado, Kubernetes volta automaticamente à versão anterior da aplicação.
  • Execução em Batch: permite rodar comandos em batch como containers.

Openshift

Openshift é uma plataforma desenvolvida pela Red Hat que utiliza como base o Kubernetes. Atualmente há 3 distribuições:

  1. Openshift Origin: versão open source utilizada para quem deseja criar um cluster sem precisar pagar licenças.
  2. Openshift Enterprise: versão comercializada pela Red Hat baseada no Origin e suportada oficialmente pelo Red Hat Linux.
  3. Openshift Online: plataforma de serviço fornecida pela Red Hat concorrente do Heroku e Google App Engine.

Mas quais são as vantagens e diferenças entre o Openshift e Kubernetes? O Openshift introduziu algumas camadas que o tornam mais amigável e fácil de integrar com soluções de softwares utilizadas no mundo corporativo. Algumas das vantagens do Openshift em relação ao Kubernetes:

  • Source to Image (S2I) e Build Config: capacidade de obter o código fonte da aplicação a partir de um repositório Git e criar uma Imagem Docker pronta para uso. Um Build é disparado quando há uma mudança no código do repositório através de um Webhook.
  • Integrated Docker Registry: possui um Docker Registry privado utilizado para armazenar as Imagens Docker criadas pelo processo de Source to Image.
  • Image Stream: o Openshift faz tracking das Imagens Docker e recria os containers quando detecta uma mudança na Imagem.
  • Deployment Config: um macro serviço que detecta quando há uma alteração na configuração, por exemplo uma mudança no valor de uma variável de ambiente, e recria os containers.
  • Policies: políticas de autorização para usuários, permitindo por exemplo que um determinado usuário consiga apenas visualizar logs dos containers.
  • Webconsole: uma interface web amigável que possibilita escalar containers, visualizar logs de aplicações e containers e alterar configurações de pods, services, routes, deployments, etc.

Cursos gratuitos – Data Science Academy

Abaixo, alguns cursos gratuitos da Data Science Academy

Curso Gratuito de Microsoft Power BI (Carga Horária: 54 Horas):
Clique aqui
Curso Gratuito de Fundamentos de Big Data (Carga Horária: 8 Horas): 
Clique aqui
Curso Gratuito de Python Fundamentos para Análise de Dados (Carga Horária: 54 Horas):
Clique aqui
Curso Gratuito de Introdução a Ciência de Dados (Carga Horária: 8 Horas):
Clique aqui
Curso Gratuito de Fundamentos de Inteligência Artificial (Carga Horária: 8 Horas): 
Clique aqui