Forem: Wander

Comunicando JAVA com o GeminiAI

Wander — Wed, 08 Jan 2025 19:56:24 +0000

Se voce programa em Java e nunca 'brincou' com o GeminiAI, este artigo vai ser um ótimo guia introdutório, aqui vou apresentar de forma bem simples como enviar requisições ao Gemini e retornar um JSON, como uma API Rest. 🐱‍👤

O que estou usando? 👀

Java 17
Intellij Community 2024.1.1
Postman
Chave de acesso ao GeminiAI

VAMOS COMECAR 🚀

Inicie um projeto simples pelo spring initializer, e inclua as seguintes dependências no seu POM

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>1.18.36</version>
    <scope>provided</scope>
</dependency>

<dependency>
    <groupId>com.fasterxml.jackson.core</groupId>
    <artifactId>jackson-databind</artifactId>
    <version>2.18.2</version>
</dependency>

Essas dependencias vao possibilitar o uso do Lombok, RestTemplate e ObjectMapper.

Lombok: para evitarmos códigos repetitivos (famosos boilerplates) e para melhorar a legibilidade do nosso código

RestTemplate: para realizar a requisição http a API do GeminiAI

ObjectMapper: para convertermos o retorno da api do Gemini em JSON

CONFIGURANDO O RESTTEMPLATE

Vamos configurar o RestTemplate no nosso projeto Java, para isso criamos uma classe com a anotação @Configuration e com o Bean para defini-lo:

@Configuration
public class RestTemplateConfig {

    @Bean
    public RestTemplate restTemplate(RestTemplateBuilder builder) {
        return builder.build();
    }
}

CRIANDO O SERVICE

Vamos criar uma classe service para realizar a comunicação com o GeminiAI, esta classe será responsável por toda comunicação e tratamento da resposta do Gemini, e deverá ficar da seguinte forma:

@Service
public class TalkService {
    private final RestTemplate restTemplate;
    private final ObjectMapper objectMapper;

    @Value("${gemini.ai.api.url}")
    private String geminiApiUrl;

    @Value("${gemini.ai.api.key}")
    private String geminiApiKey;

    public TalkService(RestTemplate restTemplate, ObjectMapper objectMapper) {
        this.restTemplate = restTemplate;
        this.objectMapper = objectMapper;
    }

    public String callGeminiAI(TalkRequest input) {
        String url = geminiApiUrl + geminiApiKey;

        GeminiRequest request = new GeminiRequest();
        GeminiRequest.Content content = new GeminiRequest.Content();
        GeminiRequest.Part part = new GeminiRequest.Part();

        part.setText(input.getChat());
        content.setParts(Collections.singletonList(part));
        request.setContents(Collections.singletonList(content));

        HttpHeaders headers = new HttpHeaders();
        headers.setContentType(MediaType.APPLICATION_JSON);
        HttpEntity<GeminiRequest> entity = new HttpEntity<>(request, headers);

        ResponseEntity<String> response = restTemplate.exchange(url, HttpMethod.POST, entity, String.class);

        try {
            GeminiResponse geminiAIResponse = objectMapper.readValue(response.getBody(), GeminiResponse.class);

            if (geminiAIResponse.getCandidates() != null && !geminiAIResponse.getCandidates().isEmpty()) {
                GeminiResponse.Candidate candidate = geminiAIResponse.getCandidates().get(0);
                if (candidate.getContent() != null && candidate.getContent().getParts() != null && !candidate.getContent().getParts().isEmpty()) {
                    return candidate.getContent().getParts().get(0).getText();
                }
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
        return "Falha ao processar resposta da API";
    }
}

Note que nesta classe estamos usando os POJO's GeminiRequest e GeminiResponse, segue abaixo o código para cria-los

GeminiRequest

@Getter
@Setter
@AllArgsConstructor
@NoArgsConstructor
public class GeminiRequest {
    private List<Content> contents;

    @Getter
    @Setter
    @AllArgsConstructor
    @NoArgsConstructor
    public static class Content {
        private List<Part> parts;
    }

    @Getter
    @Setter
    @AllArgsConstructor
    @NoArgsConstructor
    public static class Part {
        private String text;
    }
}

GeminiResponse

@Getter
@Setter
@AllArgsConstructor
@NoArgsConstructor
@JsonIgnoreProperties(ignoreUnknown = true)
public class GeminiResponse {
    private List<Candidate> candidates;
    private UsageMetadata usageMetadata;
    private String modelVersion;

    @Getter
    @Setter
    @AllArgsConstructor
    @NoArgsConstructor
    @JsonIgnoreProperties(ignoreUnknown = true)
    public static class Candidate {
        private Content content;
        private String finishReason;
        private double avgLogprobs;
    }

    @Getter
    @Setter
    @AllArgsConstructor
    @NoArgsConstructor
    @JsonIgnoreProperties(ignoreUnknown = true)
    public static class Content {
        private List<Part> parts;
    }

    @Getter
    @Setter
    @AllArgsConstructor
    @NoArgsConstructor
    @JsonIgnoreProperties(ignoreUnknown = true)
    public static class Part {
        private String text;
    }

    @Getter
    @Setter
    @AllArgsConstructor
    @NoArgsConstructor
    @JsonIgnoreProperties(ignoreUnknown = true)
    public static class UsageMetadata {
        private int promptTokenCount;
        private int candidatesTokenCount;
        private int totalTokenCount;
    }
}

CRIANDO UM CONTROLLER

Vamos agora criar um controller para escutar uma requisição Rest e fazer o processamento através do nosso Service

@RestController
@RequestMapping("v1")
public class TalkController {
    private final TalkService talkService;

    @Autowired
    public TalkController(final TalkService talkService) {
        this.talkService = talkService;
    }

    @PostMapping("/chat-gemini")
    public TalkResponse talk(@RequestBody TalkRequest talkRequest) {
        TalkResponse response = new TalkResponse();
        response.setResponse(talkService.callGeminiAI(talkRequest));
        return response;
    }
}

Nosso controller também possui POJO's, confira o código deles abaixo

TalkRequest

@Getter
@Setter
@AllArgsConstructor
public class TalkRequest {
    private String chat;
}

TalkResponse

@Getter
@Setter
@AllArgsConstructor
@NoArgsConstructor
public class TalkResponse {
    private String response;
}

CONFIGURANDO VARIAVEIS NOS PROPERTIES

Voce precisará informar o endpoint de acesso ao GeminiAI e também a sua chave de acesso. Essas informações armazenei no arquivo properties, dado que estamos falando de um simples teste. Confira o arquivo properties com as variáveis necessárias

spring.application.name=NOME_DA_SUA_APLICACAO

gemini.ai.api.url=https://generativelanguage.googleapis.com/v1beta/models/gemini-1.5-flash:generateContent?key=
gemini.ai.api.key=SUA_CHAVE_DE_ACESSO

BORA TESTAR 🐱‍💻

Já temos uma comunicação com o GeminiAI, agora podemos testar nossa aplicação usando o postman, para isso inicie a sua aplicação no Intellij e execute a requisição no postman conforme a imagem abaixo:

CONCLUSÃO ✔
O intuito deste artigo foi introduzir programadores Java a conexao do GeminiAI com uma aplicacao Java, criando infinitas novas possibilidades de uso. Espero que tenham gostado, até a próxima! 😊

O básico de mirror do Istio

Wander — Sun, 23 Jun 2024 12:57:03 +0000

O Istio é a principal ferramenta de service mesh para o Kubernetes, ele disponibiliza diversas features para você gerenciar a sua malha de serviços, dentre essas features temos a parte de gerenciamento de tráfego onde uma das possibilidade é criar um 'mirror'. Mas o que é um mirror? um mirror permite você 'espelhar' o tráfego de requisições de um serviço para outro. E porque isso é útil? podemos encaixar essa funcionalidade em algumas situações, dentre elas vou destacar uma:

Vamos supor que você tem uma aplicação que usa o banco de dados mysql e você precisa migra-la para postgresql, porém, antes de tornar a versão migrada produtiva você quer testar o comportamento dela para ver se os dados serão salvos corretamente e se a aplicação não apresentará erros. Para isso, você pode espelhar as requisições que chegam na aplicação cuja versão utiliza o mysql para a versão que utiliza o postgresql. O tráfego continuará sendo enviado para a versão com mysql e a versão com postgresql receberá uma cópia desse tráfego, o retorno da aplicação com postgresql não é enviado ao cliente, garantindo assim que o cliente receba apenas o retorno da aplicação com mysql que já funciona, evitanto assim receber possíveis erros da versão nova com postgresql.

Interessante, não? 🔥

Vamos ver como funciona na prática? Para isso vamos precisar das seguintes ferramentas instaladas na nossa máquina:

⚠️ Os comandos citados abaixo para criar os componentes começam com a instrução istioctl kube-inject -f, esta instrução injeta no pod a ser criado o container de proxy do istio, para que o istio possa controlar este pod. Caso você não queira usar esta instrução confira aqui como injetar o proxy do istio de outras maneiras.

Mãos a obra 🤝🎓

1 - Para começar, vamos subir nosso cluster minikube, primeiramente inicie o docker abrindo o docker desktop (para Windows), em seguida abra um terminal git bash e execute o seguinte comando para subir o minikube:

minikube start

2 - Instale o istio

istioctl install --set profile=demo -y

3 - Copie o código abaixo e execute no git bash para criar o deployment principal

cat <<EOF | istioctl kube-inject -f - | kubectl create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: istioapp-v1
  labels:
    app: istioapp
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: istioapp
      version: v1
  template:
    metadata:
      labels:
        app: istioapp
        version: v1
    spec:
      containers:
      - name: istioapp
        image: wandpsilva/istioapp:v1.0
        ports:
        - containerPort: 8080
EOF

4 - Agora faça o mesmo para o código abaixo para a versão 2 que receberá o tráfego espelhado

cat <<EOF | istioctl kube-inject -f - | kubectl create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: istioapp-v2
  labels:
    app: istioapp
    version: v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: istioapp
      version: v2
  template:
    metadata:
      labels:
        app: istioapp
        version: v2
    spec:
      containers:
      - name: istioapp
        image: wandpsilva/istioapp:v1.0
        ports:
        - containerPort: 8080
EOF

5 - Vamos criar o service do kubernetes

kubectl create -f - <<EOF
apiVersion: v1
kind: Service
metadata:
  name: istioapp-service
spec:
  selector:
    app: istioapp
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080
  type: NodePort
EOF

6 - Criaremos agora nosso virtualservice e destinationrule, estes são componentes do istio utilizados para gerenciamento de tráfego e neste momento possuem uma configuração básica, apenas enviar a requisição recebida para o pod v1

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: istioapp-virtualservice
spec:
  hosts:
    - istioapp-service.default.svc.cluster.local
  http:
    - route:
        - destination:
            host: istioapp-service.default.svc.cluster.local
            subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: istioapp-destinationrule
spec:
  host: istioapp-service.default.svc.cluster.local
  subsets:
  - name: v1
    labels:
      app: istioapp
      version: v1
EOF

7 - Com todos os componentes criados, vamos criar um deployment do httpbin para chamarmos a nossa aplicação e testa-la

cat <<EOF | istioctl kube-inject -f - | kubectl create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      containers:
      - name: sleep
        image: curlimages/curl
        command: ["/bin/sleep","3650d"]
        imagePullPolicy: IfNotPresent
EOF

8 - Com o httpbin criado podemos chamar o endpoint da aplicação que subimos no minikube e verificarmos o response dela pelo log do pod. Vamos então chamar a aplicação com o seguinte comando

export SLEEP_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
kubectl exec "${SLEEP_POD}" -c sleep -- curl -sS http://istioapp-service:8080/v1/istioapp/hello-word/ping

Verifique as logs dos dois pods

pod v1

export V1_POD=$(kubectl get pod -l app=istioapp,version=v1 -o jsonpath={.items..metadata.name})
kubectl logs "$V1_POD" -c istioapp

pod v2

export V2_POD=$(kubectl get pod -l app=istioapp,version=v2 -o jsonpath={.items..metadata.name})
kubectl logs "$V2_POD" -c istioapp

você deverá ver a mensagem 'PONG' na log do pod v1 e nada na log do pod v2.

9 - Vamos fazer agora o mirror funcionar, fazendo com que a chamada feita no passo 8 chegue tanto para o pod v1 quanto para o pod v2, para isso vamos configurar novamente nosso virtualservice e destinationrule, aplique as configurações abaixo

kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: istioapp-virtualservice
spec:
  hosts:
    - istioapp-service.default.svc.cluster.local
  http:
    - route:
        - destination:
            host: istioapp-service.default.svc.cluster.local
            subset: v1
          weight: 100
      mirror:
        host: istioapp-service.default.svc.cluster.local
        subset: v2
      mirrorPercentage:
        value: 100
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: istioapp-destinationrule
spec:
  host: istioapp-service.default.svc.cluster.local
  subsets:
  - name: v1
    labels:
      app: istioapp
      version: v1
  - name: v2
    labels:
      app: istioapp
      version: v2
EOF

10 - Chame novamente a aplicação

export SLEEP_POD=$(kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name})
kubectl exec "${SLEEP_POD}" -c sleep -- curl -sS http://istioapp-service:8080/v1/istioapp/hello-word/ping

Verifique a log dos pods novamente

pod v1

export V1_POD=$(kubectl get pod -l app=istioapp,version=v1 -o jsonpath={.items..metadata.name})
kubectl logs "$V1_POD" -c istioapp

pod v2

export V2_POD=$(kubectl get pod -l app=istioapp,version=v2 -o jsonpath={.items..metadata.name})
kubectl logs "$V2_POD" -c istioapp

O que aconteceu? 🤔

Como você pode notar, ambos os pods exibiram nas logs a mensagem PONG, o que significa que ambos receberam a requisição feita, porém, o pod v2 recebe apenas uma cópia do tráfego, o seu retorno seja sucesso ou falha não retorna ao cliente, o que nos dá segurança de testarmos qualquer alteração e em qualquer ambiente.

Como aconteceu? 😃

Toda a lógica do mirror fica entre os componentes virtualservice e destinationrule, analisando os arquivos acima note que o virtualservice através do atributo mirror consegue replicar o tráfego para um outro subset (v2), este subset é configurado no destinationrule e lá dizemos através de labels para qual pod a requisição deverá ser enviada. Também é possível dizer o percentual de tráfego que deverá ser espelhado com o atributo mirrorPercentage, se este for omitido, 100% do tráfego será espelhado.

Este artigo foi baseado na documentação oficial do istio. Recomendo navegar pela documentação e explorar mais e mais do istio 🚀

Espero que tenham gostado, até a próxima. 😉

Entendendo roles no kubernetes

Wander — Sun, 10 Mar 2024 19:03:36 +0000

Você sabe a diferença entre role, rolebinding, clusterrole e clusterrolebinding? todos esses objetos fazem parte do conceito de RBAC do kubernetes, vale a pena entende-los para cuidarmos da segurança de um cluster. No começo pode ser um pouco confuso pois temos vários conceitos e objetos novos, mas neste artigo vamos esclarecer o que é cada um.

TEORIA

ROLE
Um objeto do tipo role no kubernetes é a especificação de permissões para determinadas ações sobre determinados objetos, para um namespace específico.

ROLEBINDING
O objeto rolebinding é o responsável por vincular uma ou mais roles a uma serviceaccount em um determinado namespace, quem usar esta serviceaccount terá as permissões que a role informada permite.

CLUSTERROLE
Ja o objetivo clusterrole é semelhante a role, porém esse tipo de role abrange o cluster como um todo e não se limita a um namespace especifico.

CLUSTERROLEBINDING
Serve para fazer o vinculo entre o clusterrole e quem poderá utilizar as permissões descritas no mesmo, seja uma serviceaccount, grupo ou usuário.

PRÁTICA COM ROLE E ROLEBINDING

Para a prática utilizei o minikube.

Cenário: vamos supor que temos um processo que irá deletar deployments nginx em um determinado namespace, nesse namespace não queremos nada de nginx. Esse nosso processo deve ficar dentro do seu próprio namespace (jobs) e o deployment do nginx, se existir, em outro namespace (test).

Vamos criar os namespaces, para isso, execute os comandos:

kubectl create namespace jobs
kubectl create namespace test

Agora vamos criar nosso cronjob que ficara no namespace jobs e irá deletar deployments nginx do namespace test, esse cronjob ira executar de acordo com o schedule, para escolher um período ajuste o campo schedule, para mais info sobre cron expression clique aqui. Abaixo segue o manifesto do cronjob:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: audit
  namespace: jobs
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: audit
            image: bitnami/kubectl
            command:
            - "bin/bash"
            - "-c"
            - "kubectl delete deployment nginx -n test"
          restartPolicy: Never

Utilize o comando kubectl apply -f [nome do arquivo manifesto] para criar os objetos.

Com nosso cronjob criado, vamos criar um deployment nginx no namespace test para ver se o cronjob irá deleta-lo mesmo, utilize o comando abaixo para criar o deployment:

kubectl create deployment nginx --image nginx -n test

Vamos ver se nosso cronjob já conseguiu excluir o deployment que criamos? se executarmos um kubectl get pod -n test veremos que o pod do deployment nginx continua lá:

consultando os pods do cronjob com um kubectl get pod -n jobs, os pods aparecem com erro:

ao executar o comando logs em um dos pods, recebemos a seguinte mensagem:

Isso acontece justamente pela falta de permissão, nosso cronjob tentou utilizar a serviceaccount default e esta não tem permissão para deletar deployments no namespace test, vamos corrigir isso, para começar vamos criar uma serviceaccount:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: jobs-sa 
  namespace: jobs

Agora vamos criar a nossa role:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: audit-job-role
  namespace: test
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "create"]
  - apiGroups: ["extensions"]
    resources: ["deployments"]
    verbs: ["get", "list", "create", "delete"]
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "create", "delete"]

Como falamos no começo do artigo, precisamos vincular esta role a serviceaccount e para isso usamos o objeto rolebinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: audit-job-rolebinding
  namespace: test
subjects:
  - kind: ServiceAccount
    name: jobs-sa
    namespace: jobs
roleRef:
  kind: Role
  name: audit-job-role
  apiGroup: rbac.authorization.k8s.io

Depois de criarmos todos esses objetos, nosso cronjob precisa de uma atualização, precisamos informar a serviceaccount que ele deverá utilizar, para isso, atualize o manifesto conforme abaixo:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: audit
  namespace: jobs
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: jobs-sa
          containers:
          - name: audit
            image: bitnami/kubectl
            command:
            - "bin/bash"
            - "-c"
            - "kubectl delete deployment nginx -n test"
          restartPolicy: Never

Agora, estamos informando qual serviceaccount deverá ser usada, e com isso nosso cronjob executa com sucesso:

Se buscarmos por deployments no nosso namespace test, não encontraremos mais o nginx:

E com isso terminamos nossa prática com role e rolebinding, vale lembrar que quando criamos a role, rolebinding e serviceaccount nós informamos o namespace, ou seja, tudo limitado a escopo de namespace, para não termos essa limitação podemos utilizar os objetos clusterrole e clusterrolebinding.

CONCLUSÕES FINAIS
o RBAC é um poderoso mecanismo para controlarmos o acesso em um cluster kubernetes, é possível de forma detalhada refinar os acessos que cada usuário ou aplicação tem dentro do cluster. Os exemplos dados aqui foram apenas para demonstrar conceitos básicos de permissão em um cluster kubernetes, vale consultar a documentação oficial para se aprofundar no assunto.

Espero que tenham gostado, até a próxima!!

Validação dinâmica K8s

Wander — Tue, 12 Sep 2023 18:24:09 +0000

Neste artigo vou abordar um componente do kubernetes que precisei entender sua função para avaliar sua real necessidade para uma determinada situação, o objeto em questão é o ValidatingWebhookConfiguration.

O ValidatingWebhookConfiguration é um dos componentes utilizados para acionar validações aos objetos que estão sendo criados, deletados ou atualizados em um cluster Kubernetes. Isso é possível pois este componente realiza chamadas a um serviço que validará por exemplo, se um pod atende ou não a determinadas regras para poder ingressar ou não no cluster.

QUANDO USAR?
Vamos supor que você não quer que sejam criados pods sem a label "ambiente: teste" no seu cluster. Para conseguir validar se este pod atende ou não a sua necessidade e permitir que ele seja criado, você criará um serviço de validação que será acionado por um ValidatingWebhookConfiguration.

Para entender melhor, vamos analisar o manifesto abaixo que especifica a criação de um ValidatingWebhookConfiguration:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: pod-validator
webhooks:
  - name: pod.validator.teste.io
    clientConfig:
      service:
        name: pod-validator
        namespace: default
        path: "/validate"
    rules:
      - apiGroups:
          - ""
        apiVersions:
          - "v1"
        operations:
          - CREATE
          - UPDATE
        resources:
          - pods
    failurePolicy: Fail

name é o nome que damos ao webhook.
clientConfig especifica o serviço que fornecerá a validação. Nesse caso o nome do service é pod-validator e está no namespace default, suponhamos que este aponte para um pod que executa um script python, esse script irá conter a lógica de validação, como por exemplo, verificar se o POD que está sendo criado possui a label "ambiente: teste".
rules aqui você descreve a 'quem' essa política se aplica, no caso do exemplo, essa validação será acionada sempre que houver um evento do tipo CREATE e UPDATE para recursos do tipo POD cujo apiVersion seja v1.
failurePolicy o valor Fail faz com que a criação do pod falhe caso a validação feita pelo nosso script python não retorne com sucesso.

O desenho abaixo explica de forma bem macro o fluxo quando o ValidatingWebhookConfiguration está presente:

PONTOS IMPORTANTES:

Você pode validar qualquer tipo de componente do kubernetes, não só PODs, se você especificar "*" no campo resources por exemplo, o serviço será chamado para qualquer tipo de recurso que estiver sendo criado ou atualizado no cluster.
Você pode restringir a validação aos recursos que estejam sendo criados em apigroups específicos, para isso, basta especificar na lista de apiGroups do manifesto os grupos no qual deseja realizar a validação, por exemplo o grupo gateway.networking.k8s.io.

RESUMO
O ValidatingWebhookConfiguration é um componente importante para que possamos controlar as operações de CREATE, UPDATE, DELETE e CONNECT de recursos em um cluster, chamando serviços que validam determinadas configurações que precisam ou não estar presentes nos recursos para que sejam 'aceitos'. É possível fazer ajustes precisos para se alcançar qualquer tipo de política de validação.

REFERÊNCIAS:

Valeu e até a próxima! :)

Obtendo mais do Kubectl

Wander — Sat, 24 Jun 2023 18:36:46 +0000

Que tal se aprofundar um pouco mais no kubectl e tirar mais benefícios dessa ferramenta? vamos conhecer alguns comandos que podem te ajudar a ganhar tempo, trazer conhecimento sobre seu cluster e recursos, depurar e análisar pods e etc.

ADMINISTRANDO

o kub te explica: o comando explain fornece informações sobre os recursos do kub. Caso você esteja com dúvida na composição de um recurso como um deployment, role e etc, você pode usa-lo para ter um norte, veja o exemplo abaixo:
kubectl explain roles

será que pode? Este comando pode ser útil para administradores do cluster, pois permite verificar se um usuário ou grupo tem permissão para executar uma determinada ação.
kubectl auth can-i delete deploy

você pode ser ainda mais específico e perguntar se uma determinada service account tem permissão:
kubectl auth can-i list pods -n default --as system:serviceaccount:default:default

quero uma lista do que tem: este comando pode ajudar a descobrir os tipos de recursos que podem ser criados no cluster.
kubectl api-resources

hmm contextos: quando se trabalha com vários clusters é interessante você usar o comando get-contexts para obter dados de todos os clusters configurados e saber em qual cluster você está 'logado'.
kubectl config get-contexts

para alternar para outro contexto use o comando:
kubectl config use-context [nome do contexto]

me fale sobre você kub: para obter alguns dados sobre o seu cluster, você pode usar o comando abaixo:
kubectl cluster-info

quero um arquivinho: em determinados momentos pode ser necessário obter o manifesto de um recurso já criado no cluster, seja por não ter mais o manifesto em algum lugar ou por simplesmente querer estuda-lo. É possível fazer isso exportando-o com a flag -o e especificando seu formato, no exemplo abaixo estou extraindo o manifesto do meu deployment que está no cluster para a minha máquina no formato yaml com o nome novo_deploy.yaml:
kubectl get deploy nginx-deployment -o yaml > novo_deploy.yaml

quero recursos por labels: as labels são muito úteis no kub e podemos usa-las para filtrar os recursos que queremos ver, um exemplo disso é obter uma lista de pods por labels:
kubectl get pods -l app=nginx

DEPURANDO

me dê logs rapaz: para visualizar as logs de um pod usamos o comando logs + [nome do pod] + [namespace], confira abaixo:
kubectl logs nginx-deployment-8cf88777f-l8s2g -n default

caso queira ver diretamente as logs do container, basta adicionar a flag -c seguido do nome do container.

para consultar e acompanhar as logs do pod basta adicionar a flag -f (--follow):
kubectl logs -f nginx-deployment-8cf88777f-l8s2g -n default

o que está acontecendo? o comando get events vai te dar uma visão por namespace dos eventos que estão ocorrendo no cluster.
kubectl get events -n kube-system

você pode filtrar os eventos para visualizar por exemplo apenas informações de um determinado recurso.
kubectl get events -n default --field-selector involvedObject.name=nginx-deployment-8cf88777f-l8s2g

descreve ai pra mim: para analisar as configurações de um recurso criado no cluster você pode usar o comando describe, além disso, no final dos dados retornados por este comando é possível verificar o status/eventos relacionados ao recurso.
kubectl describe pod nginx-deployment-8cf88777f-l8s2g -n default

'entra no pod': o comando exec --it permite executar comandos dentro de um pod ou container. Para executa-lo use kubectl exec --it [nome do pod] + [comando], veja:
kubectl exec -i -t nginx-deployment-8cf88777f-l8s2g -- /bin/bash

para acessar o container ao invés do pod basta incluir a flag -c e o nome do container na frente:
kubectl exec -i -t nginx-deployment-8cf88777f-l8s2g -c nginx-container -- /bin/bash
use 'exit' para sair do pod

mais e mais infos: a flag -o wide expande as informações da listagem de um determinado recurso, pode ser usado com pods, nodes, deployments, services e etc, e pode ser util para rapidamente detectar alguma anomalia como por exemplo ips incorretos.
kubectl get pods -o wide

BÔNUS

reiniciando deployments: kubectl rollout restart deployment [nome do deployment] -n [namespace]
desfazendo um deployment: kubectl rollout undo deployment [nome do deployment]
aumentando o número de replicas de um pod: kubectl scale deployment [nome do deployment] --replicas=3 -n [namespace]

CONCLUSÃO

Neste artigo abordei de forma simples alguns comandos pouco conhecidos da ferramenta kubectl que podem ajudar na administração de um cluster kubernetes. Utilizei o minikube para montar um cluster local e fiz o deploy de um servidor nginx para demonstrar os comandos. Abaixo os links onde você pode obter os recursos utilizados e documentações para conhecer mais comandos e mais variações:

Espero que o artigo tenha sido útil para você! 😛

Atualizando website estático no Amazon S3 via github actions com uma action personalizada

Wander — Mon, 01 May 2023 19:07:35 +0000

Tenho como objetivo aqui trazer um pouco do poder do github actions, mas como único escopo. Não serão abordados temas como criação de um website, criação de conta AWS, configuração de um bucket S3 na AWS e criação de credenciais AWS.

Bora lá? :)

ACTION

No repositório github do seu site, crie na raiz do projeto a pasta .github, e dentro desta pasta uma nova pasta chamada workflows:

Agora crie dentro da pasta .github outra pasta com nome actions, dentro da pasta actions crie um arquivo com o nome action.yaml (o arquivo precisa se chamar action e ter o formato yaml), este arquivo será a action que será acionada por um workflow para fazer o upload dos arquivos do site. Este arquivo deverá ficar da seguinte forma:

name: 'Upload S3'
description: 'esta action envia arquivos para o amazon S3'
inputs:
  bucket:
    description: 'Nome do bucket S3'
    required: true
  region:
    description: 'A região do bucket'
    required: false
    default: 'sa-east-1'
  files:
    description: 'Caminho dos arquivos para upload'
    required: true
runs:
  using: 'node16'
  main: 'main.js'

Esta action recebe 3 parâmetros de entrada (inputs), o nome do bucket, a region do bucket e o caminho dos arquivos para upload. Logo abaixo dos inputs temos o campo runs que chamará um script 'main.js' executado com node versão 16.

Agora vamos criar o script main.js que informamos acima na action, este arquivo deverá ficar dentro da pasta actions e conterá o seguinte código javascript:

const core = require('@actions/core');
const exec = require('@actions/exec');

function: run() {
  const bucket = core.getInput('bucket', { required=true });
  const region = core.getInput('region', { required=true });
  const files = core.getInput('files', { required=true });

  const uri = `s3://${bucket}`
  exec.exec(`aws s3 sync ${files} ${uri} --region ${region}`)

  core.notice('Arquivos enviados com sucesso!')
}

run();

Nesse script importamos algumas libs para manipular comandos shell e também obter os inputs informados na action. A função run() lê os inputs da action e em seguida monta a uri do nosso bucket, então é executado o comando para sincronizar os arquivos contidos no caminho informado pelo input 'files' com o bucket informado no input 'uri'.

WORKFLOW

Nossa action está pronta e nosso script de upload também, agora vamos montar o workflow que chamará essa action e enviará os inputs necessários para o upload dos arquivos.

Para isso, crie dentro da pasta workflow um arquivo com o nome de sua preferência no formato .yaml, aqui vou chama-lo de upload.yaml e ele terá o seguinte conteúdo:

name: Upload

on:
  push:
    branches:
      - main

jobs:
  upload:
    runs-on: ubuntu-latest
    steps:
      - name: Get code
        uses: actions/checkout@v3
      - name: Upload files
        uses: ./.github/actions
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        with:
          bucket: 'my-bucket'
          region: 'sa-east-1'
          files: ./files

Esse workflow sera acionado toda vez que houver um push na branch main, definimos isso com o campo 'on', para conhecer mais formas de acionar o workflow clique aqui.

Na sequência definimos o job 'upload' e informamos que ele utilizará o SO 'ubuntu' na sua ultima versão, essa imagem de SO já trás pra nós algumas ferramentas importantes como a CLI da AWS que usamos para fazer o upload dos arquivos dentro do nosso script main.js. Clique aqui e confira todas as ferramentas que já vem no ubuntu-latest.

Definimos então os steps do job, o primeiro step 'Get code' fará o download do nosso repositório, isso é necessário pois este diretório contém a action e os scripts que queremos executar, além de conter os arquivos que queremos enviar para o bucket S3.

No step seguinte 'Upload files' chamamos a nossa action, note que no campo uses estou informando o caminho onde está a nossa action criada, o arquivo action.yaml será detectado automaticamente pelo github. Passamos também os 3 inputs necessários para a action executar, o nome do bucket, a region e o caminho dos arquivos que devem ser enviados ao bucket (no meu repositório, criei uma pasta chamada files e dentro dela residem os arquivos .html, por isso no input files declarei ./files)

Passamos também as credenciais da AWS no campo 'env' para que o nosso script 'main.js' consiga através dessas credenciais enviar os arquivos ao bucket sem nenhum problema de acesso.

CREDENCIAIS AWS

As credenciais devem ser obtidas no console AWS e armazenadas no github na forma de secrets conforme abaixo:

Para criar os secrets conforme imagem acima, basta ir na aba 'Settings' do github e então no menu lateral esquerdo procurar por 'secrets and variables' e escolher a opção 'actions'.

PRONTO

Agora nossa action customizada está pronta e sempre que houver um push na branch main, nossos arquivos são enviados para o bucket S3 na AWS.

Considerações:

O seu bucket S3 deverá estar configurado como um website estático, clique aqui para entender como fazer isso.
A action que criamos aqui reside dentro do repositório do próprio website, porém esta action pode ser criada separadamente em um repositório onde apenas ela reside, nesse caso os arquivos da action devem ficar todos na raiz do repositório e não na pasta .github.
Este exemplo envia arquivos para um bucket S3, mas abre possibilidades para vários cenários na AWS, como acessar uma EC2, criar um secret no AWS Secrets Manager dentre outros.
Este tipo de action customizada só funciona com código javascript que é aceito pelo github, mas caso queira usar outra linguagem como python, java e etc, você deverá usar actions com containers docker.
Você pode usar uma action fornecida pela própria AWS para configurar sua credenciais ou outras formas de acesso, veja como clicando aqui.

CONCLUSÃO

O Github Actions é uma ferramenta poderosíssima e que todo dev precisa conhecer, através dela conseguimos dentro do nosso próprio repositório de código realizar várias tarefas como testes, deploys, validações, checagens personalizadas e etc, vale muito a pena se aprofundar no tema e conhecer cada vez mais, espero que este artigo tenha agregado algum conhecimento a você, confira a documentação oficial das actions clicando aqui.

Abraços! :)

Sending AWS SQS messages with JAVA

Wander — Sat, 24 Dec 2022 21:41:39 +0000

Hello, I’d like to share with you a quick tutorial about how to send messages to a SQS queue in AWS in a simple way using a REST API with JAVA, in this tutorial I won’t get into about themes such as security and architecture, just the comprehension about the basics of access and SQS handle.

I’m using:

JAVA 11 with Spring 2.3.3
IntelliJ
Maven 4.0.0

It’s necessary to have a little bit of knowledge about AWS accounts and SQS queues to go with this tutorial, just a bit, really!

you’ll need to include the following dependencies on your POM file:

<dependency> <groupId>com.amazonaws</groupId> <artifactId>aws-java-sdk</artifactId> <version>LATEST</version> </dependency>

Now we have to put some access information in our properties file to authentication in AWS and to tell which SQS queue we want to use (aws.queue). The access and secret key are informed in AWS console when you created it:

aws.access_key_id= aws.secret_access_key= aws.queue= aws.region=sa-east-1

ATTENTION: aws.region=sa-east-1 indicates the region where I am, check the correct region for you in AWS website.

With a configuration class we make the reference to the information that we put in our properties file above, and then we get authenticated in AWS using a Bean sqsClient:

@Configuration
public class AWSConfig {

    @Value("${aws.access_key_id}")
    private String awsId;

    @Value("${aws.secret_access_key}")
    private String awsKey;

    @Value("${aws.region}")
    private String region;

    @Bean
    public AmazonSQS sqsClient(){
        BasicAWSCredentials basicAWSCredentials = new BasicAWSCredentials(awsId, awsKey);
        return AmazonSQSClientBuilder.standard().withRegion(Regions.fromName(region)).withCredentials(new AWSStaticCredentialsProvider(basicAWSCredentials)).build();
    }
}

Once our configuration is done we create then a service to send messages to the queue:

@Service
public class SQSService {

    @Autowired
    private AmazonSQS sqsClient;

    @Value("${sqs.queue}")
    private String queueUrl;

    public void sendMessage(String msg) {
        SendMessageRequest send_msg_request = new SendMessageRequest()
                .withQueueUrl(queueUrl)
                .withMessageBody(msg)
                .withDelaySeconds(5);
        sqsClient.sendMessage(send_msg_request);
    }
}

I am indicating the queue which I want to access in my properties file and using an amazon interface (AmazonSQS), so I can invoke the method sendMessage which receives as an argument a SendMessageRequest object. The method withDelaySeconds tells in seconds the delay to deliver the message to the queue.

To access our method I’ve created an specific service to AWS tests, this one will be called by our Controller class:

@Service
public class AWSTestService {

    @Autowired
    private SQSService sqsService;

    public void sendMessage(SQSMessage sqsMessage) {
        String msg = sqsMessage.getMsg();
        sqsService.sendMessage(msg);
    }
}

In this service I’m injecting the service we’ve created to send the message

To receive the message as a RequestBody I’ve created a basic domain class:

public class SQSMessage {
    private String msg;

    public SQSMessage(){}

    public SQSMessage(String msg) {
        this.msg = msg;
    }

    public void setMsg(String msg) {
        this.msg = msg;
    }

    public String getMsg() {
        return msg;
    }
}

Lastly, using the domain class the Controller can call the methods we’ve created and send the message that we are receiving in our request body:

@RestController
@RequestMapping("/awstest")
public class AWSTestController {

    @Autowired
    private AWSTestService service;

    @PostMapping(value="/message")
    public ResponseEntity<Void> sendMessage(@RequestBody SQSMessage sqsMessage){
        service.sendMessage(sqsMessage);
        return ResponseEntity.ok().build();
    }

}

Now you can test it using postman and checking the amazon console in SQS section the messages you are producing coming.

This was my first write here. I hope you like it. :-)