DEV Community: Vinícius Beloni

Rodando banco de dados no docker!

Vinícius Beloni — Fri, 03 Jun 2022 03:24:25 +0000

"Vocês não me escolheram, mas eu os escolhi para irem e darem fruto, fruto que permaneça, a fim de que o Pai lhes conceda o que pedirem em meu nome.
Este é o meu mandamento: amem-se uns aos outros".
"Se o mundo os odeia, tenham em mente que antes odiou a mim."
- João 15.16-18

Quem nunca precisou subir o próprio banco de dados para testar as alterações feitas numas tabelas? Melhor ainda manter isso versionado e rodando em container. Hoje vou compartilhar com vocês como fazer isso.

Sumário

Criando o projeto
Dockerfile
Rodando
Versionando
Github Actions
Fontes

Criando o projeto

Topo

Vamos iniciar criando um projeto para o DB, esse projeto será responsável por verificar se seu banco está tudo certo. Mas antes devemos instalar o template MSBUild.Sdk.Sqlproj:

> dotnet new --install MSBuild.Sdk.SqlProj.Templates
> dotnet new sqlproj -n MyDb -o my-db/src -s Sql130
> cd my-db
> dotnet sln -n MyDb
> dotnet sln add src #se exitir um .sqlproj pode adicionar também

Perceba que foi criado um arquivo chamado MyDb.csproj, ele será responsável por gerenciar o Pre e PostDeploy e "compilar" todo o seu banco de dados. Vamos criar umas tabelas, depois voltaremos para mexer neste arquivo.

> mkdir src/Schemas
> mkdir src/Tables

> 'CREATE SCHEMA [Bible]' > src/Schemas/Bible.sql

> 'CREATE TABLE [Bible].[Verse](
>>  [VerseId] INT,
>>  [Content] VARCHAR(MAX)
>> )
>> ' > src/Tables/Verse.sql

> dotnet build

Ao fazer isso, será concluído o build com sucesso. Ao criar um script incorreto, será lançado o erro no seu terminal:

> 'CREATE SCHEMA [Pimba] errrrou' > src/Schemas/Pimba.sql
> dotnet build
EXEC : error SQL46010: Incorrect syntax near errrrou. [...]

Agora vamos criar o script de PostDeploy e adaptar o arquivo MyDb.csproj para buscar as Seeds:

> mkdir src/PostDeploy
> '' > src/PostDeploy/SeedTables.sql

SeedTables.sql:

PRINT 'Merging [Bible].[Verse]'

MERGE INTO [Bible].[Verse] AS TARGET
USING 
(
VALUES
    (1, 'Joao 15.16'),
    (2, 'Joao 15.17'),
    (3, 'Joao 15.18')
)
AS SOURCE ([VerseId], [Content])
ON TARGET.[VerseId] = SOURCE.[VerseId]
WHEN NOT MATCHED BY TARGET THEN
    INSERT ([VerseId], [Content])
    VALUES ([VerseId], [Content])
WHEN MATCHED THEN
    UPDATE SET
        TARGET.[Content] = SOURCE.[Content];

Adaptando o MyDb.csproj:

<Project Sdk="MSBuild.Sdk.SqlProj/2.0.0">
    <!-- [...] -->

    <!-- Adicione este bloco para utilizar o PostDeploy -->
    <ItemGroup>
        <Content Include=".\**\*.sql" />

        <!--Remove all Seed files from the build, but add them as post-deploy https://github.com/rr-wfm/MSBuild.Sdk.SqlProj/issues/103 -->

        <Content Remove="..\**\Seed\*.sql" />
        <Content Remove=".\PostDeploy\SeedTables.sql" />

        <PostDeploy Include=".\PostDeploy\SeedTables.sql" />
    </ItemGroup>
</Project>

Vamos testar:

> dotnet build
[...]
Build succeeded.
    0 Warning(s)
    0 Error(s)

Dockerfile

topo

Agora com suas tabelas funcionando, vamos rodar em um container:

Dockerfile (UTF-8):

ARG DBNAME=MyDb
ARG PASSWORD=C0mposed

FROM mcr.microsoft.com/dotnet/sdk:5.0-buster-slim AS build
WORKDIR /src

COPY src .
RUN dotnet build ./MyDb.csproj -c Release -o /app/build

FROM mcr.microsoft.com/mssql/server:2017-latest AS final

# Install Unzip
RUN apt-get update \
    && apt-get install unzip -y

# Install SQLPackage for Linux and make it executable
RUN wget -progress=bar:force -q -O sqlpackage.zip https://go.microsoft.com/fwlink/?linkid=2165213 \
    && unzip -qq sqlpackage.zip -d /opt/sqlpackage \
    && chmod +x /opt/sqlpackage/sqlpackage

# Add the DACPAC to the image
COPY --from=build /app/build/MyDb.dacpac /tmp/db.dacpac

# Configure external build arguments to allow configurability.
ARG DBNAME
ARG PASSWORD

# Configure the required environmental variables
ENV ACCEPT_EULA=Y
ENV SA_PASSWORD=$PASSWORD

# Launch SQL Server, confirm startup is complete, deploy the DACPAC, then terminate SQL Server.
# See https://stackoverflow.com/a/51589787/488695
RUN ( /opt/mssql/bin/sqlservr & ) | grep -q "Service Broker manager has started" \
    && /opt/sqlpackage/sqlpackage /a:Publish /tsn:. /tdn:$DBNAME /tu:sa /tp:$SA_PASSWORD /sf:/tmp/db.dacpac \
    && rm /tmp/db.dacpac \
    && pkill sqlservr

Resumidamente estamos criando o nome da instância do banco de dados e fazendo o deploy do DACPAC que geramos. Para mais detalhes os links estarão no final do artigo.

Agora vamos ver se está criando o container corretamente:

> docker build -t my-db .
[+] Building 57.5s (15/15) FINISHED [...]

Rodando

topo

Com tudo preparado, só falta executar o container:

> docker run --name testando -p 1433:1433 my-db
SQL Server 2019 will run as non-root by default.
This container is running as user root.
Your master database file is owned by root. [...]

Para conectar utilize as seguintes informações(SQL Login):
user: sa
pwd: C0mposed
server: localhost, 1433

Os próximos passos serão versionar e configurar o Github Actions.

Versionando

topo

Crie o repositório normalmente, eu criarei no Github:

git init
git remote add origin https://github.com/confianodev/my-db-container
git branch -M main
git fetch
git pull origin main
git add .
git commit -m ":tada: a better commit message"
git push --set-upstream origin main
git checkout -b dev

Dessa forma, qualquer pessoa que for evoluir as tabelas, views, schemas, indexes, etc. Devem conseguir versionar, compilar e executar o banco de dados.

Github Actions

topo

Agora precisamos automatizar isso para que ninguém fique refém dos testes locais. Lembre-se de criar a secret PACKAGES_TOKEN na organização ou no próprio repositório.

mkdir .github/workflows
'' > build-homolog.yml
'' > release-homolog.yml
'' > rollback-homolog.yml

Conteúdo dos arquivos:
https://github.com/confianodev/my-db-container/blob/main/.github/workflows
Lembre-se de trocar o meu usuário(confianodev) pelo seu.

Feito isso, basta fazer o commit e seu container está pronto para ser compartilhado!

git add .
git commit -m ":wrench: github actions"
git push --set-upstream origin dev

E é isso pessoal, a ideia não é fazer deploy em produção, mas sim facilitar os testes e evitar perder tempo com scripts no banco de homologação. Espero que tenha ajudado.

Fiquem com a graça e paz do nosso Senhor Jesus Cristo!

Fontes

topo

https://github.com/rr-wfm/MSBuild.Sdk.SqlProj
https://itnext.io/how-to-build-and-run-a-sql-container-using-a-dacpac-file-c7b0d30f6255

[Avançado] Criando templates customizados em C#

Vinícius Beloni — Tue, 10 May 2022 15:53:52 +0000

Portanto, se alguém está em Cristo, é nova criação. As coisas antigas já passaram; eis que surgiram coisas novas!
2 Coríntios 5.17

Sumário:

Estrutura final
Preparando a solução
Criando repositório remoto
Github Secrets
Configurando o pacote
Publicando o template
Fontes
Agradecimentos

No tutorial anterior vimos juntos como criar um template de um jeito bem simples, agora porém, vamos escalar a simplicidade e criar uma solução completa de forma replicável, onde teremos publicação automática utilizando Github Actions, Nuget registry e muito mais!

Estrutura final

voltar ao topo

PS C:/repos/my-templates> tree /f
│   .gitignore
│   TemplatePack.csproj
│
├───.github
│   └───workflows
│           publish.yml
│
└───templates
    └───customapi
        │   .dockerignore
        │   .editorconfig
        │   .gitattributes
        │   .gitignore
        │   Dockerfile
        │   MyProject.sln
        │
        ├───.template.config
        │       template.json
        │
        ├───src
        │   │   appsettings.Development.json
        │   │   appsettings.json
        │   │   MyProject.csproj
        │   │   Program.cs
        │   │   WeatherForecast.cs
        │   │
        │   ├───Controllers
        │   │       WeatherForecastController.cs
        │   │
        │   └───Properties
        │           launchSettings.json
        │
        └───tests
                MyProject.Tests.csproj
                UnitTest1.cs

Vamos começar criando um diretório para hospedar os templates, pois com esse tutorial será possível ter vários em um único pacote. Então para a API vamos criar dois projetos, um para o código de produção(src) e outro para testes de unidade(tests) mas fique a vontade para seguir o que funciona pra você, também vamos criar uma solution e outros arquivos.

Preparando a solução

voltar ao topo

> mkdir templates/customapi
> cd templates/customapi
> dotnet new webapi --no-https -n MyProject -o src
> dotnet new xunit -n MyProject.Tests -o tests
> dotnet new sln -n MyProject
> dotnet add ./tests/ reference ./src
> dotnet sln add ./src/ ./tests/

Agora vamos criar o restante dos arquivos (Encoding: UTF-8):

> '' > Dockerfile
> '' > .editorconfig
> '' > .gitignore
> '' > .dockerignore
> '' > .gitattributes
> mkdir .template.config
> '' > .template.config/template.json

.gitignore:

https://github.com/github/gitignore/blob/main/VisualStudio.gitignore

Dockerfile:

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build

# remover se não usar .editorconfig
ENV PATH="$PATH:/root/.dotnet/tools"
RUN dotnet tool install -g dotnet-format

WORKDIR /src
COPY . .

RUN dotnet restore
RUN dotnet build -c Release --no-restore
RUN dotnet test -c Release --no-build

# remover se não usar .editorconfig
RUN dotnet format --verify-no-changes

RUN dotnet publish "src/MyProject.csproj" -c Release --no-build -o /app/publish

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS final
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "MyProject.dll"]

.dockerignore:

**/.classpath
**/.dockerignore
**/.env
**/.git
**/.gitignore
**/.project
**/.settings
**/.toolstarget
**/.vs
**/.vscode
**/*.*proj.user
**/*.dbmdl
**/*.jfm
**/azds.yaml
**/bin
**/charts
**/docker-compose*
**/Dockerfile*
**/node_modules
**/npm-debug.log
**/obj
**/secrets.dev.yaml
**/values.dev.yaml
LICENSE
README.md

.gitattributes:

* text=auto
*.cs text eol=crlf

.editorconfig (Opcional):
Padrão do .NET
O padrão que eu utilizo

Para formatar seu código instale o dotnet format e execute o seguinte comando:

> dotnet tool install -g dotnet-format
> dotnet format

template.json:
Podemos seguir o mesmo do tutorial anterior:

{
    "$schema": "http://json.schemastore.org/template",
    "author": "@confianodev",
    "identity": "MyCustomWebApi",
    "name": "My Custom Web Api",
    "shortName": "customapi",
    "preferNameDirectory": false,
    "sourceName": "MyProject",
    "classifications": ["Web API", "API"],
    "tags": {
        "language": "C#",
        "type": "project"
    }
}

Criando repositório remoto

voltar ao topo

Agora começa as diferenças, no caso como estamos trabalhando com multiplos projetos e até templates, vamos criar um arquivo .csproj na raiz da nossa solução. Este arquivo terá várias informações para empacotar todos os templates e publicá-los posteriormente, mas antes vamos criar um repositório remoto.

Vá até o Github, crie um novo repositório vazio e siga este passo-a-passo:

> cd ../..
> git init
> git add .
> git commit -m "initial template files"
> git branch -M main
> git remote add origin https://github.com/SEU-USER/seurepo.git
> git push -u origin main

Github Secrets

voltar ao topo

Para publicar o pacote devemos criar um Token, basta criar um Personal Access Token com permissões de write:packages e copiar o conteúdo, depois vá para a aba
Setting > Secrets > Actions do repositório que criamos e clique em "New repository secret", ao pedir um Name coloque como "PACKAGES_TOKEN" (válido para este tutorial, mas pode colocar o nome que quiser) e no Value cole o Token que você acabou de criar.

Configurando o pacote

voltar ao topo

Com tudo isso pronto, vamos criar nosso arquivo de template que será utilizado pelo comando dotnet pack. Lembrando que o campo <RepositoryUrl> precisa ser preenchido corretamente com o nome do repositório que acabamos de criar, caso contrário teremos problemas ao publicar o nosso pacote:

> '' > TemplatePack.csproj

TemplatePack.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <PackageType>Template</PackageType>
    <PackageVersion>1.0.0</PackageVersion>
    <PackageId>my.templates</PackageId>
    <Title>My Templates</Title>
    <Authors>@confianodev</Authors>
    <RepositoryUrl>ALÔ, GALERA DE COWBOY</RepositoryUrl>
    <RepositoryType>git</RepositoryType>
    <Description>Templates utilizados para criar meus projetos HAHA</Description>
    <PackageTags>dotnet-new;templates;</PackageTags>
    <TargetFramework>net6.0</TargetFramework>
    <IncludeContentInPack>true</IncludeContentInPack>
    <IncludeBuildOutput>false</IncludeBuildOutput>
    <ContentTargetFolders>content</ContentTargetFolders>
    <NoDefaultExcludes>true</NoDefaultExcludes>
    <NoWarn>$(NoWarn);NU5128</NoWarn>
  </PropertyGroup>

  <ItemGroup>
    <Content Include="templates\**\*" Exclude="templates\**\bin\**;templates\**\obj\**" />
    <Compile Remove="**\*" />
  </ItemGroup>
</Project>

Para mais informações, acesse este link.

Customize do jeito que for melhor, nesse momento poderiamos aplicar nossos padrões, criar classes de apoio(repositórios, métodos de extensão, configurações de log, startup, etc). Após tudo feito, podemos testar:

> dotnet test templates/customapi/tests
> dotnet run --project templates/customapi/src

Agora vamos empacotar tudo e testar nosso novo template, pois o próximo passo será jogar isso para o Nuget:

> dotnet pack
> dotnet new -i ./bin/Debug/my.templates.1.0.0.nupkg
> dotnet new customapi -n Pimba -o sample
> rm /sample
> dotnet new --uninstall my.templates

Excelente! Template testado e funcional, agora vamos automatizar a publicação de novas versões e publicar o nosso pacote Nuget.

Publicando o template

voltar ao topo

Vamos configurar o Github Actions:

> mkdir .github/workflows
> '' > .github/workflows/publish.yml

publish.yml:

name: CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
      - name: Setup .NET 6 # atualize se for necessário
        uses: actions/setup-dotnet@v1
        with:
          dotnet-version: 6.0.202 # atualize se for necessário

      - name: Generate package
        run: dotnet pack -c Debug -o out --include-symbols --include-source --verbosity Detailed

      - name: Publish NuGet
        run: |
          cd out
          dotnet nuget push *.nupkg --api-key ${{ secrets.PACKAGES_TOKEN }} --source https://nuget.pkg.github.com/SEU-USER/index.json --skip-duplicate

Faça o commit das alterações e vamos ver o resultado do Github Actions:

> copy ./templates/customapi/.gitignore .gitignore
> git add .
> git commit -m "add publish action"
> git push

Se tudo deu certo, na aba Actions do seu reposítorio o pacote estará sendo preparado e pronto para ser utilizado. Mas agora que seu pacote está disponível, precisamos adicioná-lo localmente:

Observação: Vou utilizar o Token que criei acima, mas o ideal para utilizar pacotes privados é criar um outro Token somente com o acesso read:packages.

> dotnet nuget add source "https://nuget.pkg.github.com/SEU-USER/index.json" -n Github -u "SEU-USER" -p "TOKEN-QUE-CRIAMOS" --store-password-in-clear-text
> dotnet new -i my-templates
> dotnet new customapi -n Opa -o sample

Saída do meu terminal:

PS C:\repos\criando-template> dotnet new -i power.templates
The following template packages will be installed:
   power.templates

Failed to download package 'power.templates.1.0.0' from 'https://nuget.pkg.github.com/confianodev/download/power.templates/1.0.0/power.templates.1.0.0.nupkg'.
The HTTP request to 'GET https://nuget.pkg.github.com/confianodev/download/power.templates/1.0.0/power.templates.1.0.0.nupkg' has timed out after 100000ms.
Warning: Failed to scan C:\repos\criando-template\src.
Details: Template package location C:\repos\criando-template\src is not supported, or doesn't exist.
Success: power.templates::1.0.0 installed the following templates:
Template Name  Short Name  Language  Tags       
-------------  ----------  --------  -----------
My Web Api     customapi   [C#]      Web API/API

Para adicionar novos templates, basta criar novas pastas e projetos dentro da pasta templates assim como fizemos para a templates/customapi:

Exemplo:

> mkdir templates/customrobot
> cd templates/customrobot
> dotnet new console -n MyProject -o src

E é isso! Fico muito feliz de ter compartilhado com você esta experiência. Espero que consiga aumentar a sua produtividade e das pessoas que trabalham com você. Qualquer dúvida por favor deixem nos comentários!

Até a próxima, se assim o Senhor Pai nos permitir, Abraços!

Fontes

voltar ao topo

Como criar um pacote modelo
Working with the Nuget registry
https://docs.microsoft.com/pt-br/nuget/nuget-org/publish-a-package

Agradecimentos

voltar ao topo

Agradecimentos especiais ao SammyROCK, pois trabalhando com ele aprendi muita coisa, principalmente sobre Docker, Github Actions, Secrets, Nuget Registry, etc. Obrigado!

[Simples] Criando templates customizados em C#

Vinícius Beloni — Sat, 07 May 2022 17:58:25 +0000

"Sejam bondosos e compassivos uns para com os outros, perdoando-se mutualmente, assim como Deus os perdoou em Cristo."
Efésios 4.32

Provavelmente você já viu ou utilizou o comando dotnet new para criar projetos usando o ~~novo~~ .NET, então vou te mostrar como criar seu próprio template customizado!

Pré-requisitos (para este tutorial):

Vou criar o template de um projeto Web API, mas podemos criar templates de arquivos ou até estruturas completas com Dockerfile, .editorconfig, .sln, estruturas de pastas e etc, tudo depende da sua necessidade (ou criatividade). Mas para este tutorial faremos da forma mais simples e útil para este momento, então vamos prosseguir.

Com o terminal do VSCode aberto, vamos criar um projeto do tipo Web API, customizar e remover o que for desnecessário.

> dotnet new webapi --no-https -n MyProject -o src
> ri src/WeatherForecast.cs
> ren src/Controllers/WeatherForecastController.cs MyController.cs

Faremos algumas alterações no arquivo MyController.cs (caso seja iniciante não copie o código, mas escreva linha por linha).

using Microsoft.AspNetCore.Mvc;

// MyProject será substituido pelo nome do projeto ao criar o template
namespace MyProject.Controllers;

[ApiController]
[Route("[controller]")]
// WeatherForecast foi renomeado para My
public class MyController : ControllerBase
{
    private readonly ILogger<MyController> _logger;

    public MyController(ILogger<MyController> logger)
    {
        _logger = logger;
    }

    [HttpGet()]
    public string Get()
    {
        _logger.LogInformation("Hello World");
        return "Olá Mundo";
    }

    [HttpPost()]
    public void Post([FromBody] object body)
    {
        _logger.LogInformation($"received {body}");
    }
}

Agora vamos rodar para ver se está tudo certo:

> dotnet run --project src
Building...
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5172
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: C:\repos\criando-template\src\

Eu utilizo uma extensão chamada REST Client para fazer as requisições usando o próprio VSCode para testar coisas mais rapidamente, mas você pode utilizar o Postman se preferir ou o próprio navegador no caso do método GET. Para não confundir ninguém vou mostrar o resultado do meu terminal ao fazer as requisições.

info: MyProject.Controllers.MyController[0]
      Hello World
info: MyProject.Controllers.MyController[0]
      received { "confia": "no Pai" }

Agora com a nossa Web API customizada, vamos configurar o nosso template:

> mkdir ./src/.template.config
> '' > ./src/.template.config/template.json

Conteúdo do arquivo template.json:

{
    "$schema": "http://json.schemastore.org/template",
    "author": "@confianodev",
    "identity": "My Web Api",
    "name": "My Web Api",
    "shortName": "myapi",
    "preferNameDirectory": false,
    "sourceName": "MyProject",
    "classifications": ["Web API", "API"],
    "tags": {
        "language": "C#",
        "type": "project"
    }
}

Vou dar uma breve explicação de alguns desses campos, lembrando que podemos adaptar essas informações:

author - Nome de quem tem a propriedade intelectual deste template(você, a empresa, uma organização).

shortName - O nome que será utilizado no comando, exemplo: dotnet new myapi

preferNameDirectory - Caso seja true será gerado o projeto dentro de uma pasta com o nome informado(dotnet new myapi -n EsseNome) caso seja false não cria pasta nenhuma.

sourceName - Muito importante pois é a palavra-chave que vai substituir arquivos, namespace, textos, etc, ao criar um novo projeto usando o seu template (dotnet new myapi -n PalavraChave).

tags - Utilizado para informar qual o tipo do template e quais linguagens são suportadas(podemos criar em F# também)

Para mais informações pode acessar este link.

Finalmente, vamos instalar nosso template, criar um projeto e testá-lo:

> dotnet new -i .
> dotnet new myapi -n Oloko -o sample
> dotnet run --project sample/
Building...
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5172
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: C:\repos\criando-template\sample\

E está pronto o nosso template. Lembrando que a ideia do template é facilitar a criação de novos projetos e novos arquivos, então crie da maneira que for mais útil para o seu dia-a-dia.

Caso queria desinstalar basta utilizar o comando:

> dotnet new --uninstall .

Claro que este é o jeito mais simples de fazer um template, no próximo Post vou mostrar como criar uma solução completa, com dois projetos e uma solução, com Dockerfile, padronização de código e etc, utilizando o github actions para publicar como pacote Nuget.

Fico muito agradecido de ter compartilhado este conhecimento com você, se tiver alguma dúvida deixe nos comentários.

Acesse meu canal no YouTube clicando aqui
E caso queria ir para o post mais avançado, clique aqui

Abraços e até a próxima!

Fontes:

Donovan Brown: Custom Templates for dotnet new
How to create your own templates
Templating Wiki