lpsm-dev

lpsm-dev

lpsm-dev

use database
db.createUser(
  {
    user: "validation",
    pwd: "123456",
    roles: [{role: "read", db: "ato"}]
  }
)

lpsm-dev

USE master
GO
DECLARE @kill varchar(max) = '';
SELECT @kill = @kill + 'KILL ' + CONVERT(varchar(10), spid) + '; '
FROM master..sysprocesses 
WHERE spid > 50 AND dbid = DB_ID('cadastro')
EXEC(@kill);

GO
SET DEADLOCK_PRIORITY HIGH

lpsm-dev

USE [database];
CREATE LOGIN [user] WITH PASSWORD = '123456';
CREATE USER [user] FOR LOGIN [user];
EXEC sp_addrolemember db_datareader, [user];

lpsm-dev

# Stage 1 - the build process
FROM node:10-alpine as build-deps
WORKDIR /src
COPY package.json package-lock.json ./
RUN npm i --silent
COPY . ./
RUN npm run build

# Stage 2 - the production environment
FROM nginx:1.12-alpine

lpsm-dev

Intro

Mesmo com o passar do tempo, um profissional precisa continuamente demonstrar suas skills de profissionalismo e maturidade. Quanto se trata de um profissional da área de TI introduzido em um contexto de desenvolvimento de software, isso também não é diferente. Programadores sêniors devem ser capazes de incentivar o uso de boas práticas para construção do seu software, como:

• Utilização de um sistema de versionamento e controle de código.
• Testes unitários e de integração.
• Cultura DevOps.
• Implementação de um metodologias de CI/CD.

E por ai vai... Atualmente é essencial a existência de um software capaz de manter o versionamento das suas entregas e controle do que está sendo modificado em seu software. Uma das soluções mais utilizadas é o Git.

lpsm-dev

mkdir -p ~/gitlab
rm -rf ~/gitlab/.gitconfig
cat << EOF >> ~/gitlab/.gitconfig
[user]
    name = lpmatos
    email = lpmatos@gmail.com
EOF

mkdir -p ~/github
rm -rf ~/github/.gitconfig

lpsm-dev

EMAIL=""
HOST="gitlab.com"
ssh-keygen -t rsa -b 4096 -C "$EMAIL"
ssh -T git@$HOST

lpsm-dev

Kubernetes: Node Taints and Tolerations

Overview

Embora haja uma pequena diferente, eu gosto da explicação do Google sobre a questão dos node taints. No Kubernetes quando você envia uma carga de trabalho para ser executada em um cluster, o scheduler determina onde colocar os pods associados à essa carga de trabalho. O scheduler é livre para colocar um pod em qualquer node que satisfaça os requisitos de recursos personalizados de CPU e de RAM do pod. Se o cluster executa várias cargas de trabalho, convém exercer um controle sobre quais cargas de trabalho podem ser executadas em um pool de nodes em particular.

Com um node taint você marca um node para que o scheduler do kubernetes evite ou impeça o uso dele em determinados pods. Com o recurso adicional de tolerations; que permite designar pods para serem usados em nodes tainted ou contaminados, você designa pods que podem ser usados em nodes com taints.

Node taints são