Teste-Devops-DataRisk

.github/workflows/apply-dev.yml

@@ -0,0 +1,45 @@
+name: Apply terraform resources dev
+
+on: [workflow_dispatch]
+
+env:
+  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
+  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
+
+jobs:
+  apply-dev:
+    name: 'terraform apply dev'
+    runs-on: ubuntu-latest
+    env:
+      TF_WORKING_DIR: 'terraform'
+
+    defaults:
+      run:
+        shell: bash
+        working-directory: ${{ env.TF_WORKING_DIR }}
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+
+      - name: Setup Terraform
+        uses: hashicorp/setup-terraform@v1
+        with:
+          terraform_version: 0.15.5
+
+      - name: Terraform fmt
+        id: fmt
+        run: terraform fmt
+
+      - name: Terraform Init
+        id: init
+        run: terraform init
+
+      - name: Terraform Validate
+        id: validate
+        run: terraform validate -no-color
+
+      - name: Terraform Apply
+        run: terraform apply -auto-approve
+
+

.github/workflows/destroy-apply.yml

@@ -0,0 +1,45 @@
+name: Destroy terraform resources on the given folder
+
+on:
+  workflow_dispatch:
+    inputs:
+      dir:
+        description: 'Directory with resources to be destroyed'
+        required: true
+        default: 'terraform'
+
+env:
+  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
+  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
+
+jobs:
+  destroy-dev:
+    name: 'terraform destroy dev'
+    runs-on: ubuntu-latest
+    env:
+      TF_WORKING_DIR: ${{ github.event.inputs.dir }}
+
+    defaults:
+      run:
+        shell: bash
+        working-directory: ${{ env.TF_WORKING_DIR }}
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+
+      - name: Setup Terraform
+        uses: hashicorp/setup-terraform@v1
+        with:
+          terraform_version: 0.15.5
+
+      - name: Terraform Init
+        id: init
+        run: terraform init
+
+      - name: Terraform Validate
+        id: validate
+        run: terraform validate -no-color
+
+      - name: Terraform Destroy
+        run: terraform destroy -auto-approve

.github/workflows/push-registry-ghcr.yml

@@ -0,0 +1,53 @@
+# name: Docker Image GHCR
+
+# on:
+#   workflow_dispatch
+
+# jobs:
+#   build_and_publish:
+#     runs-on: ubuntu-latest
+#     steps:
+#       - uses: actions/checkout@v3
+#       - name: GitHub Docker registry
+#         uses: matootie/[email protected]
+#         with:
+#           accessToken: ${{secrets.GH_PAT}}
+#           tag: latest
+#           tag_with_ref: true
+#           tag_with_sha: true
+
+# # Dockerfile 2
+
+name: build-and-publish-container-image
+
+on: [workflow_dispatch]
+
+jobs:
+  build-and-publish-container-image:
+    runs-on: ubuntu-latest
+
+    steps:
+    - name: Checkout code
+      uses: actions/checkout@v2
+
+    - name: Set up Docker Buildx
+      uses: docker/setup-buildx-action@v1
+
+    - name: Build and tag Docker image
+      run: |
+        short_commit=$(git rev-parse --short HEAD)
+        cd projeto-fsharp
+        docker build . -t ghcr.io/richardneves/projeto-fsharp:latest -t ghcr.io/richardneves/projeto-fsharp:${short_commit}
+
+    - name: Login to GitHub Container Registry
+      uses: docker/login-action@v1
+      with:
+        registry: ghcr.io
+        username: ${{ github.actor }}
+        password: ${{ secrets.GH_PAT }}
+
+    - name: Push Docker image
+      run: |
+        short_commit=$(git rev-parse --short HEAD)
+        docker push ghcr.io/richardneves/projeto-fsharp:${short_commit}
+        docker push ghcr.io/richardneves/projeto-fsharp:latest

.gitignore

@@ -0,0 +1,36 @@
+# Local .terraform directories
+**/.terraform/*
+/.terraform/*
+
+# .tfstate files
+*.tfstate
+*.tfstate.*
+
+# Crash log files
+crash.log
+
+# Ignore any .tfvars files that are generated automatically for each Terraform run. Most
+# .tfvars files are managed as part of configuration and so should be included in
+# version control.
+#
+# example.tfvars
+
+# Ignore override files as they are usually used to override resources locally and so
+# are not checked in
+override.tf
+override.tf.json
+*_override.tf
+*_override.tf.json
+
+# Include override files you do wish to add to version control using negated pattern
+#
+# !example_override.tf
+
+# Include tfplan files to ignore the plan output of command: terraform plan -out=tfplan
+# example: *tfplan*
+
+.idea
+*.zip
+node_modules
+.terraform
+.DS_STORE

README.md

@@ -1,30 +1,24 @@
 # Datapi DevOps Challenge
 
-Para melhor entendermos o seu nível técnico, nós preparamos este desafio como parte do nosso processo de contratação. Por isso, tenha em mente que não é necessário cumprir com todos os pontos mencionados, nem cumpri-los em uma ordem específica.
+Documentação do projeto
 
-O importante é entregar o que você conseguir fazer, com a devida documentação.
+# Instanciação de Maquina Virtual EC2 AWS:
 
-# Desafios
+Foi escolhida a cloud AWS para realização do projeto e Deploy por questão de familiaridade. Porém não afeta no funcionamento do projeto.
 
-Segue abaixo uma lista de desafios abrangendo várias áreas de responsabilidade para um DevOps no time do Datapi. Nossa sugestão é tentar seguir cada item na ordem apresentada, porém você está livre para atuar nos pontos que quiser e tiver mais familiaridade.
+Onde é utilizado pelo arquivo apply-dev.yml para deploy na AWS. Utilizando Steps e jobs basicos para entrega da maquina EC2 na AWS 
 
-- Instanciar uma VM numa cloud provider. Recomendação: Microsoft Azure.
-    - Criar a configuração dessa VM usando uma ferramenta de IaC (Infrastructure as Code). Recomendação: Terraform.
-    - Criar um job de CI (Continuous Integration) para aplicar a configuração da ferramenta de provisionamento. Recomendação: GitHub Actions.
-- Adicionar um Dockerfile à aplicação disponibilizada na pasta `projeto-fsharp/` para containerizar o mesmo. Note que foi utilizada a linguagem F# (.NET) para escrever a aplicação. Para facilitar o entendimento do projeto, adicionamos um README.md com instruções de teste e uso do mesmo localmente. Você deverá ser capaz de traduzir essas instruções para a criação do Dockerfile.
-    - Criar um job de CI para enviar a imagem gerada para um Docker Registry. Recomendação: GitHub Container Registry.
-- Criar os manifestos YAML para hospedar a aplicação usando Kubernetes. Nesse ponto os testes podem ser realizados apenas localmente, porém devem ser apresentados os arquivos YAML criados.
-    * Utilizar IaC para configurar o Kubernetes. Recomendação: Terraform.
-    * Configurar a hospedagem a partir do registry gerado na tarefa anterior.
-    * Caso possua mais familiaridade, sinta-se motivado a customizar mais as configurações (secrets, ingress, etc.).
-- Adicionar um README ao projeto detalhando o processo e justificando as decisões tomadas. Recomendação: Markdown. Todos os refinamentos adicionados nos tópicos mencionados anteriormente, e demais ideias que possam melhorar o projeto serão considerados na avaliação da solução.
+# Dockerfile:
 
-Faça um fork e envie um PR com a sua solução, o tempo de entrega é de no máximo 4 dias e será contabilizado a partir da data do fork.
+Foi realizado a construção do Docker file MultiStage onde em primeiro momento é possível baixar a imagem da Microsoft com a versão 6.0 do SDK para o bom teste e funcionamento do projeto, realizar copia dos arquivos e pastas principais para aplicação do restore.sh e criação do build. 
+Na segunda etapa de build é possível realizar a copia do build e armazenar em uma pasta especifica onde será utiliza o resultado do build a exposição da porta e utilização do arquivo ./Server em ENTRYPOINT inicialização em tempo de execução do container.
 
-## Será avaliado:
+O DockerFile é utilizado pelo arquivo de esteira na pasta .github/workflows push-registry-ghcr.yml onde existe um job basico de conexão, build e push da imagem para o registry do github onde é possível localizar em packages do repositorio.
 
-- % do que foi entregue em relação ao que foi pedido.
-- Qualidade dos aquivos Terraform.
-- Boas práticas de infra e uso do Kubernetes.
-- Corretude das tarefas.
-- Uso eficiente em relação ao custo de máquina.
+# Arquivos Terraform
+
+Arquivos básicos onde fazem a construção da EC2 na AWS e em paralelo também fazem a criação do K3S dentro da EC2 da AWS que é uma opção escolhida ao kubernetes pela praticidade em sua configuração. E é realizado o deploy da aplicação via manifesto com shell script.
+
+# Destroy terraform
+
+Existe o arquivo terraform destroy-apply.yml onde é executado manualmente o "destroy" da aplicação criada pelo terraform.

projeto-fsharp/Dockerfile

@@ -0,0 +1,17 @@
+FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
+WORKDIR /app
+
+COPY . projeto-fsharp
+RUN cd projeto-fsharp && ./restore.sh
+
+RUN cd projeto-fsharp && dotnet fake run build.fsx -t "Build"
+
+FROM mcr.microsoft.com/dotnet/sdk:6.0
+LABEL org.opencontainers.image.source="https://github.com/richardneves/Datapi-DevOps-Challenge"
+WORKDIR /app
+
+COPY --from=build /app/projeto-fsharp/src/Server/out .
+
+EXPOSE 8085
+
+ENTRYPOINT ["./Server"]

projeto-fsharp/restore.sh

@@ -1,5 +1,4 @@
 set -ex
-
 dotnet tool restore
 dotnet paket install
 dotnet paket restore

terraform/backend.tf

@@ -0,0 +1,8 @@
+terraform {
+  backend "s3" {
+    bucket  = "richardneves-tfstate"
+    key     = "dev/tfstate-challenge"
+    region  = "us-east-1"
+    encrypt = true
+  }
+}

terraform/main.tf

@@ -0,0 +1,17 @@
+data "aws_ami" "ubuntu" {
+  owners      = ["amazon"]
+  most_recent = true
+  name_regex  = "Ubuntu"
+}
+
+resource "aws_instance" "web" {
+  ami             = data.aws_ami.ubuntu.id
+  instance_type   = var.instance_type
+  security_groups = ["acesso_geral"]
+  user_data       = file("terraformando.sh")  
+  tags = {
+    Name          = "${var.environment}: App"
+    Env           = var.environment
+    Type          = var.instance_type
+  }
+}