DevOps – PowerShell – The shell cannot be started.

Introdução

Esse artigo tem como finalidade apoiar a resolução dos problemas:

– Ao tentar executar um Deploy utilizando a instrumentação PowerShell ocorre o erro: A failure occurred durin Object reference not set to an instance of an object.

– Ao tentar executar o PowerShell localmente ocorre o erro: The shell cannot be started. A failure occurred durin Object reference not set to an instance of an object.

Causa

Esse erro ocorre devido a falta da chave de registro Enviroment em HKEY_CURRENT_USER.

Solução

Logue no computador usando o usuário que apresenta a falha. Em seguida abra o editor de registro e vá em HKEY_CURRENT_USER.

image

Em seguida crie a chave “Environment” em seguida insira os valores em “Expandable String Value” Value Name: TEMP Value data: %USERPROFILE%\AppData\Local\Temp e TMP %USERPROFILE%\AppData\Local\Temp

image

Importante: Se possível compare a chave de registro de mesma versão do Windows com outro usuário para inserir algum valor adicional, que pode mudar conforme a edição do Sistema Operacional.

Por exemplo:

– Windows 10

image

– Windows 2003

image

Observe que o caminho do diretório temporário muda conforme a versão do sistema operacional.

Windows Containers–Sabe o que é um Container?

container

O que é um Container?

Eles são um ambiente operacional isolado, portátil e controlado por recursos.

Basicamente, um contêiner é um local isolado em que um aplicativo pode ser executado sem afetar o restante do sistema e sem o sistema afetar o aplicativo. Contêineres são a próxima evolução na virtualização.

Se você estivesse dentro de um contêiner, seria algo como estar em um computador físico ou máquina virtual recém-instalados. E, para o Docker, um contêiner do Windows pode ser gerenciado da mesma forma que qualquer outro contêiner.

Fonte: Windows Containers – Início Rápido

Materias:

Windows Containers – Início Rápido

O que é o Docker

Windows Containers-Instalando o Provedor de Imagens de Containers no Windows

Introdução

Esse artigo tem a finalidade de explicar como instalar um provedor de imagens de containers para ser utilizado no Windows.

Passos

Utilizando o Windows Powershell ISE, execute o comando:

Install-PackageProvider ContainerImage

image

Continuar lendo

Windows Containers–Instalando o Docker no Windows

Introdução

Nesse artigo, irei explicar os passos para instalar o Docker no Windows utilizando o Powershell. Nos próximos artigos irei explicar como CRIAR um Container, as DIFERENÇAS, e o GERENCIAMENTO dos mesmos em um ambiente Windows.

Passo 1

Instale o Windows Server 2016 com a experiência Desktop.

Passo 2

Abra o PowerShell ISE como administrador

image

Instale a Feature Container do Windows e reinicie seu servidor usando os comandos do PowerShell abaixo.

Install-WindowsFeature containers
Restart-Computer –Force

image

Continuar lendo

DevOps – Dicas para um HA e DR Efetivo com o Microsoft SQL Server – Desenvolvimento

Como sabemos, o Microsoft SQL Server 2014 e agora o Microsoft SQL Server 2016 possuem diversas features como:

– Aumento do desempenho em querys;

– Maior gerenciamento de memória e processador;

– Melhoras no AlwaysOn, garantindo maior disponibilidade;

– Melhor gerenciamento de memória;

– E muitas outras features.

Maiores informações podem ser vistas no link: https://msdn.microsoft.com/en-us/library/bb500435.aspx

Mesmo assim, temos que ter alguns cuidados ao desenvolvermos nossas aplicações que utilizam esse sistema de banco de dados pois, além de determinadas features estarem apenas nas edições mais avançadas que consequentemente custam mais, muitas das features não conseguirão realizar “milagres” em sua aplicação, e mesmo que consiga, sua aplicação terá um custo elevado e menos atrativo ao cliente final, pois demanda de um investimento pesado em software, hardware e gerenciamento.

Por exemplo:

Um banco de sua aplicação extremamente fragmentado, não irá ficar mais rápido com aumento de IOPS em seu ambiente;

Um banco de dados com tamanho elevado exige maior plano de DR (Disaster Recovery) e consequentemente necessidade de locais redundantes para ativações de replicação, necessitando de uma maior infraestrutura com link, IOPS e memória.

Também exige mais recursos para um HÁ (High Available) efetivo devido ao tempo de recuperação do banco de dados no momento de um HA via Cluster Failover;

Um banco de dados com tamanho elevado pode ocasionar lentidão no processamento e consulta de dados do Banco de Dados, sendo necessário constantes manutenções de limpeza, alterações no código da aplicação, entre outras situações;

Dificuldade em sua aplicação trabalhar em ambientes compartilhados ou em nuvem, devido a quantidade de dados e forma de processamento, dificultando a implantação em clientes (on-premise) e em Cloud (Azure e AWS), desde de manutenção e gerenciamento, até preços, etc.;

Sendo assim, segue algumas dicas para análise e considerações que auxiliará o time de Infraestrutura na gestão de DR e HA, oportunizando um RTO (Recovery Time Objective) bem alinhado com seus clientes e parceiros de negócio.

Separar Banco de Dados de Processamento/Configuração/Armazenamento

– Vantagens:

· Priorizar os bancos de processamento em instâncias que possuam mais velocidade, memória e disco;

· Planos de backup diferenciados, entre os bancos de dados, por exemplo banco de processamento, pois seus dados são mais voláteis e descartáveis;

· Recuperação de desastre mais rápida, pois a restauração dos dados torna-se mais rápida, diminuindo o tempo de inatividade do cliente;

Manter dados voláteis nos Bancos de Processamento, com rotinas de limpeza ou manutenção

– Vantagens:

· Manter o banco de dados limpo, com tamanho reduzido, facilitando o backup e a recuperação de desastres

Separar Dados Anuais/Semestrais do Banco de Dados de Armazenamento em File Groups independentes

– Vantagens:

· Backups menores, devido a separação dos backups em File Groups;

· Separação dos File Groups em áreas nobres conforme os mais usados (por exemplo, consultas feitas no ano corrente, o File Group referente ao ano, pode ficar em uma unidade mais “premium”);

Outras práticas

Além das práticas recomendadas acima, que apoiará o time de Infraestrutura nos itens de DR (Disaster Recovery) e HA (High Available) dando condições de gerenciamento efetivo dos bancos e instâncias, gestão de backups eficientes e garantia maior de proteção de dados, há outras práticas que pontuo rapidamente, que merece ser inserido em outro post.

· Construção de consultas eficientes, evitando consumo excessivo de memória, disco e processador. Essas consultas podem ser avaliadas através do Database Engine Tuning Advisor

clip_image002

· Gerenciamento efetivo dos filtros de consulta dos clientes, parametrizando por exemplos os intervalos de períodos de consultas, forma de construção dessas consultas evitando-se trazer um volume de dados consideráveis e querys “caras” para o Microsoft SQL Server. Você pode avaliar as consultas no Monitor de Atividades.

clip_image004

· Mensagens amigáveis ao usuário, evitando-se replicação consultas via navegador;

· Rotinas de criação de índices, organização de dados;

· Proteção no banco de dados de armazenamento de documentos, evitando querys (dados apagados ou alterados) que possam comprometer os dados armazenados, pois dependendo da situação um backup pode não proteger;

E muitas outras práticas que estarei abordando de forma macro no próximo post.

No próximo post, darei pequenas dicas ao time de Operações para ter um HA e DR efetivo.

Até a próxima!

Alan Carlos