No processo, surgiu a idéia de automatizar a entrega de scripts do PowerShell, além de sincronizar o trabalho em equipe entre os administradores de sistema com os scripts em execução em diferentes servidores. O artigo foi desenvolvido para administradores de vitórias simples, não familiarizados com os problemas do git, gitlab, ci / cd e outros devops, portanto, se você estiver interessado, pergunte no item cat.
Vamos começar com os problemas que surgiram ao trabalhar
- falta de versionamento;
- inconsistência entre colegas ao finalizar scripts;
- perda de scripts úteis quando os colegas saem;
- entrega manual de scripts para locais de sua execução;
- bagunça banal.
Todos esses problemas são realmente pequenos em casos isolados, mas quando tudo isso já está na escala da equipe e nos montes de scripts, eu gostaria de colocar as coisas em ordem.
Para simplificar minha vida, usei o maravilhoso produto Gitlab, já implantado conosco e usado por codificadores. Não considerarei
o processo de instalação do gitlab e do
gitlab-runner , apenas esclareceremos que já temos um
gitlab configurado
com autorização de domínio e um runner do Windows separado com o
executor do
powershell , que executará nossas tarefas de implantação. Para scripts, eu uso o excelente
código do Visual Studio .
Organizamos o trabalho no gitlab
Então, aqui vamos nós, para iniciantes, precisamos formar um grupo no gitlab, que incluirá todos os nossos administradores de sistema.
Em seguida, adicione nossos colegas aos membros com direitos de desenvolvedor e você poderá começar a criar o projeto. Criamos o projeto em nosso grupo, para que nossos colegas tenham acesso automaticamente a ele.
Após a criação do projeto, na primeira página, haverá todas as dicas sobre o tópico "o que fazer a seguir". No nosso caso, precisamos iniciar os arquivos existentes da nossa estação de trabalho no gitlab. Por exemplo, tudo isso está no diretório "E: \ scripts \ powershellmegaproject". Use o prompt apropriado e execute no seu computador:
cd E:\scripts\powershellmegaproject git init git remote add origin http://gitlab.domain.net/sysadminsdev/powershellmegaproject.git git add . git commit -m "Initial commit" git push -u origin master
Bingo! Todos os nossos arquivos do diretório "E: \ scripts \ powershellmegaproject" estão agora em nosso projeto.
O que vem a seguir? Abra o VSCode e tente fazer alterações em nosso script do PowerShell localizado neste diretório. Depois de salvar o arquivo, veremos uma notificação na seção Controle de origem, onde você pode ver as alterações e fazer uma confirmação. Em seguida, enviamos para o servidor:
Vamos verificar no site do projeto no gitlab, haverá o conteúdo real dos arquivos e, no histórico de confirmações, você pode acompanhar as alterações.
Configuração de CI / CD
É hora de configurar a entrega de scripts para o servidor. Para que o CI / CD funcione, um corredor deve estar disponível para o seu projeto. Você pode atribuí-lo no admin gitlab - runners ou usar corredores compartilhados.
E agora para o projeto. Para que o CI / CD funcione, é necessário criar um arquivo .gitlab-ci.yml no diretório com nosso projeto com uma descrição das ações (você também pode ver uma dica e ajuda sobre isso ao acessar o menu gitlab - CI / CD - Pipelines). Você pode escolher vários métodos para a entrega de arquivos, desde apenas copiar arquivos para rsync ou git pull no servidor desejado. Como estamos considerando o cenário mais simples, ele apenas copiará o PowerShell. Para fazer isso, você precisa disponibilizar publicamente a pasta no servidor de destino com o script na rede e fornecer acesso de alteração ao usuário sob o qual nosso serviço gitlab-runner está em execução.
Preencha .gitlab-ci.yml com conteúdo simples:
deploy_stage: variables: DEST_DIR: \\srv-megaserver\scripts\powershellmegaproject script: - remove-item -path $DEST_DIR\* -recurse - gci -Recurse | Copy-Item -Destination $DEST_DIR
Aqui, escrevemos o caminho para o nosso diretório em uma variável (em outros projetos, você pode simplesmente copiar esse arquivo e alterar o diretório de destino) e, com um simples comando powershell, primeiro excluímos todo o conteúdo do diretório e, em seguida, copiamos tudo do nosso projeto para esta pasta.
Confirmar, enviar alterações e verificar. Em nossa pasta no servidor, todos os arquivos devem ser atualizados. Você pode ver o status e a execução do Pipeline na mesma seção de nossos pipelines gitlab - ci / cd -, um exemplo de execução bem-sucedida:
Running with gitlab-runner 11.3.1~beta.4.g0aa5179e (0aa5179e) on gl-runner2-windows a24eda81 Using Shell executor... Running on SRV-GL-RUNNER2... Fetching changes... HEAD is now at e6e9a2c update ci file From http://gitlab.domain.net/sysadminsdev/powershellmegaproject e6e9a2c..5f5cfce master -> origin/master Checking out 5f5cfceb as master... Skipping Git submodules setup $ remove-item -path $DEST_DIR\* -recurse $ gci -Recurse | Copy-Item -Destination $DEST_DIR Job succeeded
Suponha que neste servidor uma tarefa já tenha sido configurada para executar esse script a partir de um projeto no planejador, como resultado, sempre obtemos a execução dos arquivos reais do projeto.O que há com os colegas?
É simples, crie uma pasta para projetos, acesse-a no ps / cmd e clone o projeto para nós mesmos.
cd e:\projects git clone http://gitlab.domain.net/sysadminsdev/powershellmegaproject.git
Tudo, basta trabalhar no VSCode abrindo a pasta, fazendo confirmações e pressionando.
O que alcançamos como resultado?
- todos os scripts são armazenados no repositório;
- todo o grupo de administração pode trabalhar com scripts;
- todas as mudanças são visíveis na história;
- qualquer administrador recém-criado vê imediatamente todos os desenvolvimentos e não precisa correr pelos servidores e descobrir "onde o que é feito";
- todas as mudanças produtivas são entregues automaticamente no "local de trabalho produtivo".
Eliminamos todos os nossos problemas e também simplificamos bastante nossa vida em equipe.
Bônus
Adicione o arquivo README.md ao diretório do projeto para descrever o que acontece nesses scripts.
Adicione um arquivo de registro de alterações para descrever as alterações.
ps: o que mais você pode fazer? Você pode girar o corredor na janela de encaixe, pode configurar o agendador de maneira ansiosa , ainda pode fazer muitas coisas mais complicadas, mas o objetivo do artigo era simplificar o entendimento deste kit de ferramentas para iniciantes.