As diversas distribuições Linux existentes não são apenas o kernel Linux, propriamente dito. Todas elas são constituídas por elementos que formam a estrutura dos sistemas Linux. São elementos fundamentais para o funcionamento do sistema operacional, entre eles destaco: o bootloader, o Shell, os softwares GNU, o servidor gráfico, o ambiente desktop e muito mais. Portanto, conheça todos os elementos que compõem a estrutura dos sistemas Linux.

Contextualizando

Muito se fala… “o sistema Linux“. Contudo, o Linux “não é o todo“. Para muitos o Linux, por si, é capaz de oferecer recursos e funcionalidades completas para o computador. Entretanto, o Linux é somente o Kernel (núcleo) do sistema operacional. Todo sistema operacional (Linux, Windows e Mac, por exemplo) possui um kernel. No caso das distribuições Linux, o kernel é o Linux – livre e sendo desenvolvido por colaboradores em todo o mundo.

O kernel de um sistema é o componente central que serve “para dá vida” ao hardware. É a camada responsável por garantir que todos os programas e processos tenham acesso aos recursos da máquina de que necessitam (memória RAM, acesso ao disco e controle da CPU, por exemplo) simultaneamente, fazendo com que haja um compartilhamento concorrente desses. A grosso modo é o “cérebro” do sistema operacional; o responsável por coordenar o acesso ao hardware e dados entre os diferentes componentes do sistema.

A outra camada de um sistema operacional é constituída por elementos que oferecem recursos capazes de garantir interação com o usuário; no caso nós Popularmente referenciada como a camada de software. Esta camada permite que os aplicativos de usuário sejam executados. Entre outras palavras, o kernel do sistema não pode ser acessada diretamente pelo usuário ou administrador do sistema; isso só poderá ser possível através de aplicações utilitárias do sistema, bem como: terminal de linha de comando (CLI), softwares para compilação, software de gestão de disco/memória ou controle de processos do sistema; por exemplo.

Assim, deve ficar claro o porquê do Linux se popularizar tanto no meio técnico. Entre outros aspectos, ele, através destes aplicativos, pode ser “facilmente” acessado e controlado pelo usuário que tiver domínio e condições para isso. Além disso, pode ser estudado e distribuído livremente \o/

Por fim, feito a analogia de que o Kernel é o “cérebro” do sistema, deixo claro que o kernel por si só, assim como cérebro humano, não pode realizar todas as tarefas desempenhadas pelo sistema operacional sozinho. A união desses outros elementos com o kernel formam a estrutura do sistema Linux.

Estrutura do Linux

Ciente de que o Linux é apenas o kernel do sistema, você pode se perguntar: “Então, o que faz o sistema Linux funcionar completamente desde da inicialização ao carregamento do ambiente gráfico disponibilizado para o usuário?!”

Mesmo com todos os subsistemas do kernel (Gerenciamento de Processos, Gerenciamento de Memória, Gerenciamento de Redes, Sistema de Arquivos e outros), existem elementos que precisam compor essa base mantida no núcleo do sistema operacional para que ele funcione completamente. Entre eles destaco: o bootloader, o Shell, os softwares GNU, o servidor gráfico, o ambiente desktop e muito mais.

Todos esses elementos são desenvolvidos e mantidos por diferentes grupos de desenvolvedores. Todos independentes do desenvolvimento do kernel Linux, que é coordenado pelo Linus Torvalds (criador) e mantido pela comunidade mundial. Assim, “unindo” todos esses elementos com o Kernel Linux, um sistema operacional completo é criado – assim surgem as distribuições Linux.

Bootloader

Um Bootloader (“carregador de inicialização”), também chamado de gerenciador de inicialização (boot), é um pequeno programa que carrega o sistema operacional de um computador na memória.

Quando um computador é ligado, a BIOS ou a UEFI realiza alguns testes iniciais das atividades básicas para o correto funcionamento de todos os recursos da máquina; e então transfere o controle para o Registro Mestre de Inicialização (MBR – Master Boot Record), onde o Bootloader se encontra.

No sistemas Linux, geralmente, o gerenciador de inicialização usado é o Grub. Com ele instalado, além de gerenciar o processo de inicialização do sistema, é possível ter vários sistemas operacionais instalados e escolher qual deve ser iniciado. O Grub fornece um menu que permite que você escolha entre as opções de sistemas disponíveis. Recurso comumente chamado de “dual-boot“.

Caso não possua diversos sistemas instalados na máquina (somente uma distribuição Linux), o Grub pode inicializar o sistema Linux quase que instantaneamente. Mesmo que você não o veja, ele ainda está lá.

Em resumo, o Grub, pelo fato de ser um Bootloader, é responsável pelo processo de inicialização do Linux. Sem ele, uma distribuição Linux não iria iniciar

Shell

Primeiramente, o shell (ou interpretador de linha de comando) é um módulo que atua como camada externa (“concha“) entre o usuário e o sistema operacional. Existem diversos tipos de shell. O primeiro deles foi o Bourne shell (sh) que oferecia diversos comandos internos que permitiam ao usuário solicitar chamadas ao sistema operacional. A partir daí houveram evoluções significativas do shell.

Atualmente, a maioria dos sistemas Linux usam, por padrão, uma evolução do Bourne shell, chamada Bash (Bourne Again Shell). O Bash, além das funcionalidades das versões anteriores, também implementa um linguagem simples de programação que permite o desenvolvimento de pequenos programas (os famosos shell scripts).

Em resumo, o shell é um programa independente do usuário, executado fora do kernel, que fornece uma interface para interpretação de comandos. Ele permite a interação com o sistema executando comandos em uma interface de texto (CLI). Mesmo que você esteja apenas usando o ambiente gráfico e nunca tenha precisado usar ou executar nenhum comando Linux, o shell está em constante execução. Quando você abrir o terminal de linha de comando, você verá o shell em pleno funcionamento

Softwares GNU

O shell fornece alguns comandos básicos embutidos, mas a maioria dos comandos que podem ser executados no shell Linux não são oferecidos por ele. Por exemplo, o comando cp (para copiar um arquivo), o comando ls (para listar os arquivos em um diretório) e comando rm (para apagar arquivos) são parte do pacote utilitários básicos GNU (“coreutils“). Nem todos os utilitários e programas de linha de comando são desenvolvidos pelo projeto GNU. Alguns comandos e programas de terminais possuem o seu próprio projeto independente.

Dá pra ver que os comandos listados são fundamentais para o funcionamento do sistema Linux. Além deles, existem softwares utilitários essenciais para o funcionamento do sistema, como os utilitários de compilação e bootloader GRUB; também desenvolvidos e mantidos pelo projeto GNU. Assim, os sistemas Linux não iriam funcionar sem esses utilitários tão importantes. Tão importantes, que, na verdade, o shell Bash, propriamente dito, faz parte do projeto GNU.

Assim, diante dessa situação, você deve ter visto muitas discussões à respeito sobre a controvérsia do uso da nomenclatura “Linux” com a “GNU/Linux”. O uso, apenas, do nome “Linux” indica que somente o Linux é capaz de oferecer sozinho as funcionalidades que ele tão bem oferece. Contudo, o uso do nome “GNU/Linux” representa mais fielmente que o sistema também inclui outros softwares utilitários fundamentais para o funcionamento do sistema.

Servidor gráfico

O modo gráfico no Linux é gerado pelo servidor gráfico X (X Window System), que não é parte do kernel Linux. Entre outras funções, ele é responsável pela ativação da placa de vídeo, mouse e teclado; permitindo ao usuário o uso de interfaces gráficas que são chamadas de Gerenciadores de Janelas e Ambientes Desktops. Os Ambientes Desktops dispõem de interface completa para o usuário (GUI), bem como: barra de ferramentas, botões, ícones, wallpapers e bibliotecas gráficas. Já os Gerenciadores de Janelas dão base para os Ambientes Desktops.

Existem diversos Ambientes Desktops diferentes. E essa é uma das características mais fascinantes do mundo Linux. A possibilidade em poder personalizar seu sistema. Por exemplo, se não gostar de um Ambiente Desktop, você pode facilmente trocar por outro que se adeque as suas necessidades

Atualmente, o servidor gráfico mais popular é o X.org. Entretanto, já existem em funcionamento outros servidores gráficos em destaque, que no caso são: o Wayland e o Mir (desenvolvido pela Canonical – Ubuntu). Ambos com o propósito de serem substituto ao X Window System.

Em resumo, o servidor gráfico interage com sua placa de vídeo, monitor, mouse e outros dispositivos que preparam o ambiente para os Gerenciadores de Janelas e Ambientes Gráficos. Um servidor gráfico não fornece um Ambiente Desktop completo, apenas um sistema gráfico que Ambientes Desktop e ferramentas podem funcionar sobre ele.

Ambientes Desktops

Se você está usando uma distribuição Linux agora, o que você está realmente vendo e interagindo é um Ambiente Desktop Linux. Por exemplo, o Ubuntu oferece o Ambiente Desktop Unity, o Fedora oferece o GNOME e Linux Mint, geralmente, inclui Cinnamon ou MATE. Estes Ambientes Desktop fornecem tudo que você vê e interage – o fundo da tela, painéis, barras de título das janelas e muito mais.

Além de diversas características, os Ambientes Desktops incluem seus próprios utilitários. Por exemplo, GNOME e o Unity incluem o gerenciador de arquivos chamado Nautilus desenvolvido como parte do GNOME. Já o KDE inclui o gerenciador de arquivos chamado Dolphin, desenvolvido como parte do projeto KDE.

Em resumo, todos esses Ambientes Desktops citados são desenvolvidos independentemente do desenvolvimento do kernel Linux. Assim, diversos projetos acabam surgindo para aumentar o leque de opções disponíveis para o usuário escolher qual usar. E são nesses Ambientes Desktops que a maioria dos usuários resolvem mudar tema, cor dos ícones e outras mudanças na aparência; deixando, literalmente, “a sua cara”

---

Via | HowToGeek

O post Muito além do kernel – conheça todos os elementos que formam a estrutura do sistema Linux apareceu primeiro em Linux Descomplicado.

Depois de alguns meses em desenvolvimento, o download do Ubuntu 16.10 está disponível oficialmente. Depois das versões betas, previamente divulgadas, a última versão estável do Ubuntu 16.10 está liberada para download com melhor integração com o snap e Unity 8 disponível para testes.

Oficialmente, conforme nota de lançamento da Canonical, a versão final do Ubuntu 16.10 foi liberada para desktops, servidores e cloud. Diversas novidades são aguardadas quando se fala em divulgação de novas versões. Contudo, o Ubuntu 16.10 vem com algumas novidades; mas, sem grandes mudanças consolidadas para o usuário final.

A tão esperada migração do Mir com o Unity 8 ainda não veio por padrão, mesmo que já disponível para testes – inicialmente, pensada para desenvolvedores detectarem bugs. Outro aspecto relevante, como a cada 6 meses a Canonical lança uma versão nova; fica muito difícil divulgar grandes novidades num espaço tão curto de tempo. Por isso, as versões LTS, por serem divulgadas a cada 2 anos, sempre vêem com um aperitivo a mais.

Sendo assim, caso você seja um usuário que gosta de atualizar o sistema a cada nova versão lançada, seguem novidades presentes no Ubuntu 16.10 (Yakkety Yak):

Principais Novidades

• Pequenas correções para o ambiente gráfico Unity 7.5 e para o gerenciador de janelas Compiz;
• Melhor desempenho em máquinas virtuais – modo “Unity Low Graphics”;
• Nova versão do gerenciador de arquivos Nautilus – versão 3.20;
• Sessão preview do próximo Unity 8 disponível – limitado em tarefas básicas, por enquanto;
• Aplicativos atualizados – LibreOffice 5.2, Mozilla Firefox 49, Ubuntu Software 3.20 e outros;
• Ubuntu Software (GNOME Software) – melhor integração com aplicações Snap, por exemplo;
• Linux Kernel 4.8;
• Veja mais aqui

Download Ubuntu 16.10

– Download do Ubuntu 16.10 (64 bits)
– Download do Ubuntu 16.10 (32 bits)

Atualizar do Ubuntu 16.04 LTS para o Ubuntu 16.10

Antes saiba que o Ubuntu 16.10 terá suporte de 9 meses (término em Julho de 2017). Depois desse período, nenhuma atualização crítica será disponibilizada.

Diante disso, vá no Dash e digite “Software & Updates”. Depois de aberto, vá na aba “Updates”. Selecione na opção “Notificar-me sobre uma nova versão do Ubuntu” o item “Para qualquer nova versão”. Em seguida, pressione “Alt+F2″ e digite “update-manager” (sem as aspas).

O “Update Manager” (Gerenciador de atualizações) deverá informar a existência da nova versão Ubuntu 16.10. Por fim, clique em Atualizar e siga as instruções ;-).

Caso prefira, a opção pela linha de comando pode ser feita seguindo esse tutorial.

O post Ubuntu 16.10 liberado para download com Unity 8 disponível para testes e melhor integração com o snap apareceu primeiro em Linux Descomplicado.

Post original por Jeff Barr | em 19 setembro 2016

O AWS Cost Explorer é uma ferramenta poderosa que ajuda a visualizar, entender e gerenciar seus gastos na AWS (leia The New Cost Explorer for AWS para saber mais). Você pode ver os seus gastos por serviços ou por conta vinculada, com sua escolha de granularidade diária ou mensal. Você também pode criar filtros personalizados com base nas contas, período de tempo, serviços ou marcas que sejam de especial interesse para você.

A fim de tornar seus gastos ainda mais visíveis, estamos introduzindo algumas opções adicionais de filtragem hoje. Agora você pode filtrar a um nível mais refinado, aproximando para ver os custos na únidade mais fundamental. Você também pode diminuir o zoom, categorizar o seu uso em um alto nível que esteja alinhado com os principais componentes de uso e faturação da AWS .

Zooming In

Como você deve ter notado, a AWS monitora o seu uso em um nível muito detalhado. Cada gigabyte-hora de armazenamento do S3, cada gigabyte-mês de uso do EBS, cada hora de uso do EC2, cada gigabyte de transferência de dados para dentro ou para fora, e assim por diante. Agora você pode explorar esses custos em profundidade usando a opção de filtragem Usage Type. Depois de inserir o Cost Explorer e escolher o tipo de uso a partir do menu Filtering, agora você pode filtrar as unidades fundamentais de faturamento. Por exemplo, eu posso dar uma olhada no meu uso do diário de instâncias m4.xlarge:

Zooming out

Às vezes você precisa de mais detalhes, e às vezes você precisa de um resumo. Talvez você queira saber quanto você gasta em RDS, ou sobre os pedidos de API S3 ou em armazenamento magnético EBS. Você pode fazer isso através da filtragem em Usage Type Group.  Aqui está o meu uso geral diário do EC2.

Aqui estão alguns dos outros grupos do tipo de uso que você pode usar para filtrar (eu tive que fazer alguns truques no navegador para fazer o menu desta altura):

Já disponível

Esses novos recursos já estão disponíveis e você já pode começar a usá-los em todas as regiões da AWS.

Deixe suas dúvidas e/ou comentários aqui ou escreva diretamente para o nosso colega Jeff Barr (em inglês).

Como bem sabemos, a Samsung encerrou de vez a produção e também vendas do seu Galaxy Note 7, tudo isso em razão dos problemas que ele vinha causando, ou seja, muitos aparelhos acabaram explodindo.

Sem volta! Após dar fim a produção e venda de seu Galaxy Note 7, Samsung estima prejuízo de R$ 9,8 bilhões.

O prejuízo para a fabricante é inevitável, e agora a Samsung revelou o tamanho do estrago financeiro provocado pelo aparelho explosivo. De acordo com a companhia, a decisão irá custar cerca de 3,5 trilhões de won (o equivalente a R$ 9,8 bilhões) em lucro operacional.

Continue a leitura...

Fala pessoal, tudo bem? Hoje vim reviver o blog pra passar uma dica muito bacana que eu usei pra acessar alguns sites bloqueados na rede da faculdade e conseguir rodar uns clientes IRC de lá.

Para isso precisei de antemão possuir alguns outros recursos. A rede da faculdade bloqueava qualquer tipo de protocolo IRC, Telnet e etc mas não o SSH (?). Então aproveitei a brecha para conectar em um servidor pessoal que eu tenho na Amazon. É um recurso interessante, um ano free, máquina rapidinha e tudo mais. Tendo ela online e com a porta 22 aberta para o mundo, que normalmente já vme configurado por default, somente conectei com SSH normalmente expondo minha porta 8080 e passando os parâmetros -Nf.

 # ssh -Nf usuario@maquinahost -D 8080   

Feito isso, não feche o terminal.

Abra qualquer navegador, de preferência o Firefox. Nas configurações de rede do mesmo, vá em Preferências > Avançado > Rede > Configurações. No SOCKS Host coloque 127.0.0.1 e a porta que você abriu, no meu caso 8080.

Feito ;D

Você que tem ambientes grandes e complexos, ambiente com muitas maquinas hoje é até um pecado não automatizar ambiente.

Com o advento de Nuvem e virtualização cada vez mais teremos mais servidores e serviços separados com elasticidade.

O Ansible veio para automatizar ambiente e facilitar as tarefas chatas de atualização ou instalação de patchs e muito mais.

Eu não vou mostrar como instalar o Ansible pois é uma tarefa relativamente facil

yum install ansible ou apt-get e blá blá blá o google mostra o caminho a você que se interessar.

Introdução

Ansible é um sistema de gerenciamento de configuração fácil que pode ser usada para automatizar e organizar suas tarefas de configuração do sistema para uma grande rede de computadores. Enquanto alguns outros sistemas de gerenciamento de configuração exigem muitos pacotes diferentes para ser instalado nos sistemas de servidor e cliente, com Ansible, você só precisa instalar um componente do servidor e ter acesso SSH para as máquinas clientes.

Neste guia, vamos discutir playbooks ansible, que são forma de criar scripts automatizados para configurar computadores clientes do Ansible.

Vamos supor que você tem um servidor Ansible configurado e alguns clientes.

No nosso guia, o servidor é um Ubuntu 12.04 máquina, e os clientes que vão ser configuração também são Ubuntu 12.04 máquinas, para facilidade de explicação.

Quais são Playbooks ansible?

Playbooks ansible são uma forma de enviar comandos para computadores remotos via script através do SSH. Em vez de usar comandos Ansible individualmente para configurar remotamente os computadores a partir da linha de comando, você pode configurar ambientes complexos inteiros por meio de um script para um ou mais sistemas.

Playbooks ansible estão escritos no formato de serialização de dados YAML. Se você não sabe o que é um formato de dados, pense nisso como uma maneira de traduzir uma estrutura de dados (listas, matrizes, dicionários, etc) em um formato que pode ser facilmente armazenado no disco. O arquivo pode então ser utilizada para criar a estrutura em um momento posterior. JSON é um outro formato  de dados popular, mas YAML é muito mais fácil de ler.

Cada cartilha contém uma ou mais peças, que mapeiam hosts para uma determinada função. Ansible faz isso através de tarefas, que são basicamente as chamadas em módulos.

Explorando um Playbook Básico

Veja o comando.

--- - hosts: droplets tasks: - name: Installs nginx web server apt: pkg=nginx 
state=installed update_cache=true notify: - start nginx handlers: 
- name: start nginx service: name=nginx state=started 

Vamos em seções para que possamos entender como esses arquivos são construídos e que cada peça significa.

O arquivo começa com:

 --- 

Este é um requisito para YAML para interpretar o arquivo como um documento adequado. YAML permite que vários “documentos” em um arquivo, cada um separado por --- , mas Ansible só quer um por arquivo, de modo que este só deve estar presente na parte superior do arquivo.

YAML é muito sensível ao espaço em branco, e usa isso para agrupar diferentes peças de informação em conjunto. Você deve usar apenas espaços e não tabs e você deve usar espaçamento consistente para o arquivo a ser lido corretamente. Itens no mesmo nível de recuo são considerados elementos irmãos.

Os itens que comecem com um - são considerados itens da lista. Os itens que têm o formato de key: value operar como hashes ou dicionários. Isso é muito bonito tudo o que há para YAML básica.

Documentos YAML, basicamente, definir uma estrutura de árvore hierárquica com os que contêm elementos mais à esquerda.

Na segunda linha, temos o seguinte:

 --- - hosts: droplets 

Este é um item de lista no YAML como aprendemos acima, mas uma vez que é no mais à esquerda do nível, é também uma “peça” Ansible. Peças são basicamente grupos de tarefas que são executadas em um determinado conjunto de hosts, que lhes permitam cumprir a função que deseja atribuir a eles. Cada jogo deve especificar um host ou grupo de exércitos, como fazemos aqui.

Em seguida, temos um conjunto de tarefas:

 --- - hosts: droplets tasks: - name: Installs nginx web server 
apt: pkg=nginx state=installed update_cache=true notify: - start nginx 

No nível superior, temos “tarefas:” no mesmo nível “hosts:”. Este contém uma lista (porque começa com um “-“), que contém pares chave-valor.

O primeiro, “nome”, é mais do que uma descrição do que um nome. Você pode chamar isso de qualquer coisa que você gostaria.

A próxima chave é “apto”. Esta é uma referência a um módulo Ansible, assim como quando usamos o comando ansible e digitar algo como:

 ansible -m apt -a 'whatever' all 

Este módulo permite especificar um pacote e o estado que ele deve estar em, que é “instalado” no nosso caso. O update-cache=true parte diz a nossa máquina remota para atualizar seu cache de pacotes (apt-get update) antes de instalar o software.

O item “notificar” contém uma lista com um item, o que é chamado de “começar nginx”. Este não é um comando interno Ansible, é uma referência a um manipulador, que pode executar determinadas funções quando é chamado a partir de uma tarefa. Vamos definir o “start nginx” manipulador abaixo.

 --- - hosts: droplets tasks: - name: Installs nginx web server 
apt: pkg=nginx state=installed update_cache=true notify: - 
start nginx handlers: - name: start nginx service: name=nginx state=started 

A seção “manipuladores” existe ao mesmo nível que os “hosts” e “tarefas”. Manipuladores são como tarefas, mas eles só correr quando lhes foi dito por uma tarefa que ocorreram alterações no sistema do cliente.

Por exemplo, temos um manipulador aqui que inicia o serviço Nginx após o pacote é instalado. O manipulador não é chamado a menos que o “Instal servidor web nginx” resultados da tarefa em mudanças no sistema, o que significa que o pacote teve de ser instalado e já não estava lá.

Nós podemos salvar este em um arquivo chamado algo como “nginx.yml”.

Só por algum contexto, se você fosse escrever esse mesmo arquivo em JSON, que poderia ser algo como isto:

 [ { "hosts": "droplets", "tasks": [ { "name": "Installs nginx web server", 
"apt": "pkg=nginx state=installed update_cache=true", "notify": [ "start nginx" ] } ], 
"handlers": [ { "name": "start nginx", "service": "name=nginx state=started" } ] } ] 

Como você pode ver, YAML é muito mais compacto e maioria das pessoas diria mais legal.

Executando um Ansible Playbook

Depois de ter um guia estratégico construído, você pode chamá-lo facilmente usando este formato:

 playbook.yml ansible-playbook

Por exemplo, se queríamos para instalar e iniciar o Nginx em todos os nossos servidores, poderíamos emitir este comando:

 ansible-playbook nginx.yml 

No entanto, se nós gostaríamos de filtrar a lista , aplicar-se apenas a um desses hospedeiros, podemos adicionar um sinalizador para especificar um subconjunto dos arquivos:

 ansible-playbook -l host_subset playbook.yml

Então, se nós só quesermos instalar e executar o Nginx em um servidor, por exemplo “host3”, que poderia digitar o seguinte:

 ansible-playbook -l host3 nginx.yml 

Adicionando recursos ao Playbook

Agora a nossa cartilha tem esta aparência:

---
- hosts: droplets
  tasks:
    - name: Installs nginx web server
      apt: pkg=nginx state=installed update_cache=true
      notify:
        - start nginx

  handlers:
    - name: start nginx
      service: name=nginx state=started

É simples e funciona, em vários hosts ou em um só.

Podemos começar a expandir a funcionalidade através da adição de tarefas.

Adicionar um padrão Index Arquivo

Podemos dizer-lhe para transferir um arquivo do nosso servidor Ansible no host, adicionando algumas linhas como este abaixo:

---
- hosts: droplets
  tasks:
    - name: Installs nginx web server
      apt: pkg=nginx state=installed update_cache=true
      notify:
        - start nginx

    - name: Upload default index.html for host
      copy: src=static_files/index.html dest=/usr/share/nginx/www/ mode=0644

  handlers:
    - name: start nginx
      service: name=nginx state=started

Podemos, então, fazer um diretório chamado static_files em nosso diretório atual e coloque um arquivo index.html dentro.

 mkdir static_files nano static_files/index.html 

Dentro desse arquivo, vamos apenas criar uma estrutura básica html:

 <html> <head> <title>This is a sample page</title> </head> <body> 
<h1>Here is a heading!</h1> <p>Here is a regular paragraph. Wow!</p> 
</body> </html> 

Salve e feche o arquivo.

Agora, quando executar novamenter o playbook, Ansible irá verificar cada tarefa. Vai ver que Nginx já está instalado no host, por isso vai deixá-lo ser. Ele vai ver a nova seção tarefa e substituir o arquivo index.html padrão com o do nosso servidor.

Resultados

Quando instalar e configurar os serviços manualmente, é quase sempre necessário saber se suas ações foram bem-sucedidas ou não. Podemos cozinhar essa funcionalidade em nossos playbooks usando “registrar”.

Para cada tarefa, que pode, opcionalmente, registrar seu resultado (sucesso ou falha) em uma variável que podemos verificar mais tarde.

Ao utilizar esta funcionalidade, também temos de dizer Ansible para ignorar erros para essa tarefa, já que normalmente ele aborta a execução cartilha para aquela máquina se qualquer problema acontece.

Assim, se quiser verificar se uma tarefa falhou ou não para decidir sobre os passos subsequentes, podemos usar a funcionalidade de registo.

Por exemplo, poderíamos dizer o nosso guia estratégico para carregar um index.php  se ele existir. Se essa tarefa falhar, poderíamos em vez de tentar carregar um index.html. Vamos verificar a condição de falha na outra tarefa, porque nós só queremos fazer o upload do arquivo HTML se o arquivo PHP falhar:

---
- hosts: droplets
  tasks:
    - name: Installs nginx web server
      apt: pkg=nginx state=installed update_cache=true
      notify:
        - start nginx

    - name: Upload default index.php for host
      copy: src=static_files/index.php dest=/usr/share/nginx/www/ mode=0644
      register: php
      ignore_errors: True

    - name: Remove index.html for host
      command: rm /usr/share/nginx/www/index.html
      when: php|success

    - name: Upload default index.html for host
      copy: src=static_files/index.html dest=/usr/share/nginx/www/ mode=0644
      when: php|failed

  handlers:
    - name: start nginx
      service: name=nginx state=started

 

Esta nova versão tenta carregar um arquivo de índice PHP para o local indicado. Ela regista com sucesso da operação em uma variável chamada “PHP”.

Se esta operação foi bem sucedida, a tarefa ira remover o arquivo index.html é executado em seguida.

Se a operação falhar, o arquivo index.html é carregado em vez disso.

Conclusão

Agora, você deve ter um bom controle sobre como automatizar tarefas complexas usando Ansible.

Este é um exemplo básico de como você pode começar a construir a sua biblioteca de configuração.

Combinando definições de host e do grupo como nós aprendemos sobre este tutorial, e com variáveis disponíveis para preencher as informações, podemos começar a montar sistemas complexos que interagem uns com os outros. Em um artigo futuro, vamos discutir como implementar variáveis em nossos playbooks e criar funções para ajudar a gerenciar tarefas complexas.

Como ainda falamos de nuvem o Ansible em ambiente IaaS publico ou não é ideal.

Teste no Azure e Amazon e não precisa falar que ambiente Onpremisses, todos funcionaram.

Tem um demo sensacional no site oficial:

https://www.ansible.com/

Veja um howto facil.

Se você quer seguir para um caminho de DEVOPS o Ansible é a porta de entrada.

Espero ter ajudado.

Abraços

 

Aplicações híbridas são conceitos que fazem parte do cotidiano de muitos desenvolvedores mobile/web. Um mesmo fluxo de desenvolvimento pode gerar uma aplicação capaz de rodar em diversas plataformas mobile (IOS, Android). Quando falamos em aplicações desktop multiplataforma nos deparamos com diversas variáveis, bem como: arquitetura do sistema operacional, variáveis de ambiente, peculiaridades do sistema e outras. Assim, saiba como criar aplicações desktop multiplataforma, num único fluxo de desenvolvimento, usando JavaScript, HTML e CSS capazes de rodar normalmente em Linux, Windows e Mac.

Contextualizando

Desenvolvimento de aplicações desktops requerem o uso de tecnologias muito peculiares que se afastam um pouco das metodologias usadas em tecnologias web (percentual maior de profissionais de programação), tais como: linguagens de marcação, folhas de estilos e server-sides. Na maioria das vezes, tecnologias como C++, C#, VB.NET, JavaFX, Qt, e algumas outras, são exemplos de tecnologias que devem ou podem ser usadas para criação de aplicações desktops.

Diante dessa situação, imagine o quanto de linguagens de programação que o profissional/estudante da área têm que aprender a usar com destreza para desenvolver, especificamente, para ambientes desktops. Agora, num momento onde os softwares são “vendidos” como serviço através da web com uso massivo de linguagens como JavaScript – onde qualquer programador (ou quase todos) usam, é “nadar”, literalmente, “contra a maré” :/

Então, assim surgiu o Electron – framework open source criado para permitir que o desenvolvimento de aplicações desktop fosse facilitado usando tecnologias web amplamente utilizadas, como: JavaScript, HTML e CSS. Tornando o fluxo de desenvolvimento muito mais fácil.

Electron

Criado pela equipe do Github, o Electron, conhecido no começo como Atom Shell, foi criado usando tecnologias como o Node.js (engine JavaScript) e o Chromium (navegador open source). Amplamente aceito pela comunidade de desenvolvedores. Em produção em diversos projetos, bem como: editor Atom e outros, como o Slack, WordPress Desktop e o Visual Studio Code. Veja mais aqui aplicações criadas usando o Electron.

Em outras palavras, se você já desenvolve para a web; agora você, também, poderá desenvolver uma aplicação desktop. Já para você que não desenvolve nenhum tipo de software, mas deseja criar uma aplicação desktop a partir de uma aplicação web; com o Electron também é possível

Entre os diversos motivos que posso mostrar do porquê de usar o Electron, destaco:

• Multiplataforma – programa desktop criado com o Electron funciona em Windows, Mac e Linux;
• Uso de tecnologias web – aplicações são desenvolvidas com HTML, JavaScript e CSS;
• Open source – criado e mantido pelo GitHub;
• Nativo – menus e notificações nativas;
• Pacote completo – criação de instaladores para sua aplicação.

Criar aplicações desktop multiplataforma

Para começo de conversa, vou mostrar os primeiros passos para começar a trabalhar com o Electron e desenvolver aplicações desktop. Além do Node.js, é necessário que você também instale o pacote electron-prebuilt:

Meu ambiente de testes foi o OpenSUSE Tumbleweed.

No Debian e derivados:

Para uma aplicação bem simples, é preciso somente de três arquivos básicos:

1. package.json: arquivo que descreve a aplicação, características e dependências;
2. main.js: arquivo de inicialização da aplicação. Nele vão as configurações do tipo: tamanho da tela, posicionamento, manipular eventos do sistema, etc…
3. index.html: página HTML que será nossa view inicial para o exemplo abaixo.

Pacakge.json

{
  "name": "electron-olamundo",
  "version": "0.1.0",
  "main": "main.js",
  "description": "Um aplicativo simples para demonstração no blog Linux Descomplicado",
  "author": "linuxdescomplicado",
  "scripts": {
    "start": "electron main.js"
  }
}

Index.html

Main.js

const electron = require('electron');
 
// Módulo utilizado para controlar o ciclo de vida da aplicação
const app = electron.app;
 
// Módulo para criar uma janela nativa do seu sistema operacional 
const BrowserWindow = electron.BrowserWindow;
 
// ATENÇÃO: Se não existir uma referência global para a janela da aplicação,
// ela será fechada automaticamente quando o objeto for pego pelo Garbage Collector
let mainWindow;

app.on('ready', function() {
 
    // Uma das opções que é possível definir ao criar uma janela, é o seu tamanho
    mainWindow = new BrowserWindow({width: 800, height: 600});
 
    // Depois apontamos a janela para o HTML que criamos anteriormente
    mainWindow.loadURL('file://' + __dirname + '/index.html');
 
    // Escutamos para quando a janela for fechada
    mainWindow.on('closed', function() {
        // Remove a referência que criamos no começo do arquivo
        mainWindow = null
    });
});

Por fim, para executar essa aplicação; execute:

Converter um serviço web em uma aplicação desktop nativa

Agora, mostrarei como converter um serviço web em uma aplicação desktop nativa. Com o Electron, isso é simples de fazer Mas, o qual é a necessidade de criar aplicações desktops a partir de serviços web já existentes?!

Para usar uma aplicação web você só precisa de um navegador web. Cada serviço web requisitado é convertido em abas no seu navegador; e isso causa desconforto (diversas abas abertas) e lentidão no navegador/sistema. Criar aplicações desktop a partir de serviços web, já existente, garante uma melhor integração com a área de trabalho do sistema e pode poupar alguns recursos computacionais; pois você poderá acessar sites/serviços web específicos isoladamente.

Em resumo, isso é possível porque o Electron permite encapsular aplicações web para o uso em ambiente desktop.

Mão na massa

Meu ambiente de testes foi o OpenSUSE Tumbleweed.

Primeiramente, instale os pacotes do Node.js:

No Debian e derivados:

Agora, você deve instalar o utilitário do Node.js que irá fazer “a mágica” acontecer:

/usr/local/bin/nativefier -> /usr/local/lib/node_modules/nativefier/lib/cli.js
/usr/local/lib
└─┬ nativefier@7.0.1 
  ├── async@1.5.2 
  ├─┬ axios@0.11.1 
  │ └─┬ follow-redirects@0.0.7 
  │   └── stream-consume@0.1.0 
  ├─┬ babel-polyfill@6.13.0 
  │ ├── babel-runtime@6.11.6 
  │ ├── core-js@2.4.1 
  │ └── regenerator-runtime@0.9.5 
  ├─┬ cheerio@0.20.0 
  │ ├─┬ css-select@1.2.0 
  │ │ ├── boolbase@1.0.0 
  │ │ ├── css-what@2.1.0 
  │ │ ├── domutils@1.5.1 
  │ │ └── nth-check@1.0.1 

[
...
]

Pronto!! A seguir você pode começar a criar aplicações desktops a partir de serviços web já existentes. Basta executar:

Onde,

– linuxdescomplicado.com.br poderá ser substituído pelo site/serviço web que desejar

Em resumo, esse processo, usando o pacote nativefier, encapsula qualquer site/serviço web de forma independente, mantendo as suas características e atribuindo-lhe um ícone e nome no ambiente desktop do seu sistema. O executável junto com outros arquivos, aparecerão em uma pasta com o mesmo nome do site na pasta “home” do usuário.

O nativefier usa o Electron para criar os executáveis das aplicações encapsuladas e torná-las multiplataforma – para uso no Windows, OSX e Linux.

---

Via | MuyLinux | BlogAlexl

O post Saiba como criar aplicações desktop multiplataforma usando JavaScript, HTML e CSS apareceu primeiro em Linux Descomplicado.

Olá!

Hoje o post será um pouco diferente dos que geralmente publicamos, queremos mostrar para vocês como é possível utilizar a funcionalidade de auto complete do shell para os comandos Docker. Mas para que isso? Simples, facilidade e agilidade na execução de comandos, quem aqui nunca apertou o tab depois de digitar ‘./conf’? Então, você deve sentir falta dessa facilidade quando se utiliza os subcomandos do docker, certo? Queremos mostrar pra vocês como resolver isso.

Como você já viu aqui, existem diversos subcomandos do docker, e cada um possui diversos parâmetros que podem ser utilizados, com o docker –help você poderá visualizar as opções disponíveis.

Mas isso é chato algumas vezes, é mais fácil começar a digitar docker run --vol...[tab][tab]e deixar o autocomplete fazer o trabalho:

$ docker run --volume
--volume         --volume-driver  --volumes-from

#vamosinstalar?

No Mac OS X

O processo é simples, estando no Mac OS X temos que instalar o auto completion usando o brew:

$ brew install bash-completion

E em seguida adicionar as linhas em nosso arquivo de profile ($HOME/.bash_profile ou /Users//.bash_profile)

if [ -f $(brew --prefix)/etc/bash_completion ]; then
    . $(brew --prefix)/etc/bash_completion
fi

Você pode executar os seguintes comandos, que devem ser utilizados nesta sequência:

$ echo "if [ -f $(brew --prefix)/etc/bash_completion ]; then" | tee -a $HOME/.bash_profile
$ echo "    . $(brew --prefix)/etc/bash_completion" | tee -a $HOME/.bash_profile
$ echo "fi" | tee -a $HOME/.bash_profile

Atenção: Se não temos o homebrew instalado, veja em http://brew.sh/ mais informações de como instala-lo e utiliza-lo.

No Linux

No Linux, como sempre, é mais simples, basta instalar via gerenciador de pacotes da sua distribuição. Se for Debian like (Ubuntu, Mint, etc) usamos o apt-get:

$ sudo apt-get install bash-completion

Se for Red Hat like (RHEL, CentOS, Fedora, etc) então usamos yum:

$ sudo yum install bash-completion

Completion do Docker Engine

O arquivo está disponível em https://github.com/docker/docker/blob/master/contrib/completion/bash/docker portanto sempre que fizer uma atualização é recomendável que você baixe novamente esse arquivo para refletir os comandos e parâmetros novos disponibilizados pelo Docker.

Ao baixar devemos colocá-lo na pasta /etc/bash_completion.d/ se estivermos no Linux, se estivermos em um Mac OS X:  $(brew --prefix)/etc/bash_completion.d.

No Mac OS X

$ curl -L https://raw.githubusercontent.com/docker/docker/master/contrib/completion/bash/docker > $(brew --prefix)/etc/bash_completion.d/docker

No Linux

$ curl -L https://raw.githubusercontent.com/docker/docker/master/contrib/completion/bash/docker > /etc/bash_completion.d/docker

Completion do Docker Compose

De maneira similar o arquivo está disponível emhttps://github.com/docker/compose/blob/master/contrib/completion/bash/docker-compose . Reforçamos que sempre que fizer uma atualização é bom baixar novamente esse arquivo para refletir os comandos e parâmetros novos disponibilizados pelo Docker Compose.

Ao baixar também devemos colocá-lo na pasta /etc/bash_completion.d/ se estivermos no Linux ou devemos acrescentar a pasta do homebrew antes se estivermos em um Mac OS X: $(brew --prefix)/etc/bash_completion.d.

No Mac OS X

$ curl -L https://raw.githubusercontent.com/docker/compose/master/contrib/completion/bash/docker-compose > $(brew --prefix)/etc/bash_completion.d/docker-compose

No Linux

$ curl -L https://raw.githubusercontent.com/docker/compose/master/contrib/completion/bash/docker-compose > /etc/bash_completion.d/docker-compose

Completion do Docker Machine

O processo é praticamente o mesmo porém o docker-machine possui 3 arquivos de auto complete. Os arquivos estão disponíveis em https://github.com/docker/machine/tree/master/contrib/completion/bash .

Como dito anteriormente devemos colocá-los na pasta /etc/bash_completion.d/ se estivermos no Linux ou devemos acrescentar a pasta do homebrew antes se estivermos em um Mac OS X: $(brew --prefix)/etc/bash_completion.d.

Como são mais arquivos recomendo utilizarmos um loop para baixarmos todos em sequência utilizando apenas um comando.

No Mac OS X

machineVersion=`docker-machine --version | tr -ds ',' ' ' | awk 'NR==1{print $(3)}'`
files=(docker-machine docker-machine-wrapper docker-machine-prompt)
for file in "${files[@]}"; do
  curl -L https://raw.githubusercontent.com/docker/machine/v$machineVersion/contrib/completion/bash/$file.bash > `brew --prefix`/etc/bash_completion.d/$file
done
unset machineVersion

No Linux

machineVersion=`docker-machine --version | tr -ds ',' ' ' | awk 'NR==1{print $(3)}'`
files=(docker-machine docker-machine-wrapper docker-machine-prompt)
for file in "${files[@]}"; do
  curl -L https://raw.githubusercontent.com/docker/machine/v$machineVersion/contrib/completion/bash/$file.bash > /etc/bash_completion.d/$file
done
unset machineVersion

Observe que:

1. Se você utilizar alguma versão específica de uma dessas ferramentas basta baixar os arquivos da pasta correspondente.  Por exemplo o docker engine, da maneira que mostramos vamos pegar o arquivo que está na branch master, atualmente versão 1.12.1, para pegar na versão 1.11.0 por exemplo o arquivo fica em https://github.com/docker/docker/blob/v1.11.0/contrib/completion/bash/docker
2. O Docker disponibiliza alguns arquivos de completion para outros shells. O Docker Engine disponibiliza bash, zsh, fish e powershell como podemos ver em https://github.com/docker/docker/tree/master/contrib/completion .
3. O Docker Compose e o Docker Machine disponibilizam apenas para bash e zshcomo vemos nas urls https://github.com/docker/compose/tree/master/contrib/completion e https://github.com/docker/machine/tree/master/contrib/completion .

E era isso por hoje pessoal, agradecimento especial ao @wsilva pela dica. Já sabe, ajude divulgando o blog, e tendo dúvidas ou sugestões deixa ai nos comentários

Abraço!

Fonte: http://dumpscerebrais.com/2016/09/auto-complete-para-docker-engine-machine-e-compose/

A quinta série é quase uma doença, que mada 5 bilhões de pessoas por mês no mundo todo. Coloque telas nas janelas e ferva bem a água antes de jogá-la na calçada pra lavar os cocô.

– VAMOS LÁ BOB, VAMOS PASSEAR NA RUA, TÁ UM DIA LINDO!
– Pô… aí… peraí dono… dá só um tempinho… (risos) eu tô tendo um dia de cão (gargalhadas)…
– Você comeu aquela ração de novo, Bob?
– Quero.

Empresa de TI cria desafio online para preencher vagas de estágio.

Yahoo anuncia roubo de dados de 500 milhões de usuários, o maior da história de uma empresa.

Existem alguns países do mundo que não gostam muito de utilizar tecnologia estrangeira, a Rússia certamente é um deles, possuindo uma preocupação acima do comum, especialmente quando se trata de...

Visite o site para ver o restando do artigo...

O elementary OS é uma distribuição querida por muitas pessoas, especialmente por conta de seu design muito bem trabalhado, porém, ele é um sistema enxuto e vem com poucas aplicações por padrão, o que...

Visite o site para ver o restando do artigo...

O Nubank iniciou testes com seu novo programa de fidelidade. A empresa selecionou um grupo de usuários Android para acessar a novidade já nesta segunda-feira (12). Com o programa de fidelidade, é possível acumular pontos de acordo com os valores das compras realizadas com o cartão, que podem ser utilizados para pagar diárias em hotéis, passagens aéreas, corridas de Uber e mensalidades de serviços de streaming como Spotify e Netflix.

Segundo Cristina Junqueira, vice-presidente de desenvolvimento de negócios e cofundadora do Nubank, o programa de fidelidade foi totalmente desenvolvido pela companhia, que destacou uma equipe de 20 pessoas para trabalhar exclusivamente no projeto durante um ano. "Não queríamos ter um programa de fidelidade igual ao dos outros cartões. Esperar até o fechamento da fatura para saber quantos pontos foram creditados não faz parte da experiência que queremos oferecer", disse a executiva.

Os que têm interesse em utilizar o programa de fidelidade terão de pagar uma anuidade. O valor ainda não foi revelado pela empresa, mas os 30 primeiros dias serão gratuitos. Os testes realizados serão expandidos, a partir de outubro, também para usuários de iPhone. Até o final do ano, a empresa pretende disponibilizar o programa de recompensas para todos os clientes. Os que foram selecionados receberão um convite para aderir ao programa a partir de hoje. Para cada R$ 1 em compras, o usuário receberá 1 ponto. Na conversão para dinheiro, cada ponto valerá menos do que R$ 1, mas a empresa não revelou o valor de tal conversão.

O saldo do programa de fidelidade será exibido na tela do aplicativo e atualizado em tempo real, sempre que o usuário realizar uma compra através do cartão. Os pontos acumulados também não terão data para expirar. Para utilizar os pontos, o usuário deve realizar a compra de uma passagem aérea, por exemplo, e depois acessar o programa de fidelidade e "apagar" a despesa utilizando os pontos acumulados.

De acordo com Cristina, por enquanto o Nubank não procura novos parceiros para o programa de fidelidade, mas eles poderão ser ampliados no futuro. Com o programa de fidelidade, o Nubank espera atrair consumidores com renda maior que o dobro da média de seus clientes atuais. Mais de 5,5 milhões de brasileiros já solicitaram o cartão de crédito do Nubank desde 2013, quando a empresa foi fundada. A startup não revela quantos clientes receberam aprovação para receber, de fato, o cartão.

Via Estadão

O Windows Server 2016 mudou a forma de licenciamento.

A forma de licenciamento privilegia levar as maquinas de forma mais facil para nuvem utilizando o Hyper-V.

O licenciamento é baseado em núcleo, e não em cores fisicos.

Inicialmente é liberado 2 cores fisicos com 8 nucleos cada core, e depois em resumo é cobrado por núcleo adicional.

Olhando em forma de gráfico se você tiver um servidor físico com 2 processadores físicos totalizando 16 núcleos você estará a nível de auditoria correto.

Vamos analisar se você tiver 2 processadores e se cada processador tiver 16 núcleos vamos resumir que o segundo processador você vai pagar por núcleo adicional.

Esta outra tabela que esta no site da MICROSOFT faz um outro resumo.

	Datacenter Edition	Standard Edition
Funcionalidade básica do Windows Server
Contêineres de OSEs/Hyper-V*	Ilimitado	2
Contêineres do Windows Server	Ilimitado	Ilimitado
Nano Server
Novos recursos de armazenamento que incluem Espaços de Armazenamento Diretos e Réplica de Armazenamento**
Novas máquinas virtuais blindadas
Nova pilha de rede
Modelo de licenciamento	Core + CAL	Core + CAL
Preço+	$6,155	$882

A tendencia para empresas que querem virtualizar o ambiente e ter soluções hibridas vai facilitar.

O Windows Server 2016 versão datacenter vai te dar o poder de não ter limite de instalação de sistemas operacionais Windows Server 2016 datacenter.

Comparando com sistemas de virtualização concorrentes como Vmware, Citrix XenServer você teria que pagar para ter cada sistema operacional Windows Server 2016 Datacenter instalado.

Exemplo:

O custo final na aquisição em relação aos concorrentes sema mais baratos, sem comparação técnica.

As comparações técnicas e gostos técnicos estão muito equiparados e neste post não esta levando em consideração e sim o entendimento do licenciamento e como será econômico ao virtualizar um ambiente com Hyper-V e Windows Server 2016.

Sem sombra de dúvida vai dar um nó na cabeça de como o olhar for o licenciamento do Windows Server 2012.

Mas é um passo importante a virtualizar e mesclar seu ambiente para modelo Hibrido.

Espero que tenham gostado.

Maiores informações no site da Microsoft e white papers sobre os licenciamentos.

https://www.microsoft.com/pt-br/server-cloud/products/windows-server-2016/#MenuItem4

Abraços

 

Ferramentas de segurança ofensiva são de grande valia para profissionais de segurança uma vez que permitem testar e demonstrar vulnerabilidades em sistemas. Profissionais de TI também podem se beneficiar dessas ferramentas usando-as tanto no incremento da capacidade de defesa dos sistemas quanto na identificação de ataques, em caso de incidentes.

O site HackerTarget.com listou 11 ferramentas de segurança ofensiva (a maioria delas open source), e incluiu – para cada uma delas – as principais formas de mitigação e defesa contra seu uso.

Entre as ferramentas está o Metasploit Framework, ferramenta de código aberto usada em testes de invasão (pentests), bastante conhecida da comunidade de segurança. O framework consiste em uma série de ferramentas, exploits e códigos que podem ser utilizados através de diferentes interfaces, e é tema de um dos cursos da Academia Clavis.

Outras ferramentas listadas são o Ettercap (uma suite de ferramentas para ataques do tipo Man In the Middle – MITM), o sqlmap (ferramenta para ataques do tipo SQL injection) e o aircrack-ng – suite de ferramentas para ataques a redes sem fio.

Veja a lista completa neste link.

Primeiro a obrigação, depois a diversão

The post Um escolha difícil appeared first on Le Ninja.

Se você é como eu então adora o auto complete do bash e provavelmente digita sempre com o dedo anelar esquerdo sempre meio levantado. Por que wsilva? Porque a cada 2 ou 3 letras de um comando já uso o tab para auto completar ou pelo menos sugerir uma continuação.

Usando Docker o auto completion é vital, existem diversos subcomandos e cada subcomando tem seus parâmetros, um jeito de descobrir é digitar o seguinte comando para ver os subcomandos ou opções possíveis.

$ docker --help 

No fim do output exite a sugestão:

Run 'docker COMMAND --help' for more information on a command.

Ou seja, para ver as opções possíveis para o comando run fazemos de maneira similar:

$ docker run --help

Mas acho isso muito chato eu prefiro começar a digitar docker run --vol...[tab][tab] e o autocomplete fazer o trabalho:

$ docker run --volume
--volume         --volume-driver  --volumes-from

Instalando o Bash Completion

No Mac OS X

O processo é simples, estando no Mac OS X temos que instalar o auto completion usando o brew:

$ brew install bash-completion

E em seguida adicionar as linhas em nosso arquivo de profile ($HOME/.bash_profile ou /Users//.bash_profile)

if [ -f $(brew --prefix)/etc/bash_completion ]; then
    . $(brew --prefix)/etc/bash_completion
fi

Dá para fazer com os seguintes comandos que devem ser usados nesta sequência:

$ echo "if [ -f $(brew --prefix)/etc/bash_completion ]; then" | tee -a $HOME/.bash_profile
$ echo "    . $(brew --prefix)/etc/bash_completion" | tee -a $HOME/.bash_profile
$ echo "fi" | tee -a $HOME/.bash_profile

Atenção: Se não temos o homebrew instalado em http://brew.sh/ encontramos mais informações.

No Linux

No Linux como sempre mais simples é só instalar via gerenciador de pacotes da sua distribuição. Se for Debian like (Ubuntu, Mint, etc) usamos o apt-get:

$ sudo apt-get install bash-completion

Se for Red Hat like (RHEL, CentOS, Fedora, etc) então usamos yum:

$ sudo yum install bash-completion

Completion do Docker Engine

O arquivo está disponível em https://github.com/docker/docker/blob/master/contrib/completion/bash/docker portanto sempre que fizer uma atualização é bom baixar novamente esse arquivo para refletir os comandos e parâmetros novos disponibilizados pelo Docker.

Ao baixar devemos colocá-lo na pasta /etc/bash_completion.d/ se estivermos no Linux ou devemos acrescentar a pasta do homebrew antes se estivermos em um Mac OS X: $(brew --prefix)/etc/bash_completion.d.

No Mac OS X

$ curl -L https://raw.githubusercontent.com/docker/docker/master/contrib/completion/bash/docker > $(brew --prefix)/etc/bash_completion.d/docker

No Linux

$ curl -L https://raw.githubusercontent.com/docker/docker/master/contrib/completion/bash/docker > /etc/bash_completion.d/docker

Completion do Docker Compose

De maneira similar o arquivo está disponível em https://github.com/docker/compose/blob/master/contrib/completion/bash/docker-compose . Reforçamos que sempre que fizer uma atualização é bom baixar novamente esse arquivo para refletir os comandos e parâmetros novos disponibilizados pelo Docker Compose.

Ao baixar também devemos colocá-lo na pasta /etc/bash_completion.d/ se estivermos no Linux ou devemos acrescentar a pasta do homebrew antes se estivermos em um Mac OS X: $(brew --prefix)/etc/bash_completion.d.

No Mac OS X

$ curl -L https://raw.githubusercontent.com/docker/compose/master/contrib/completion/bash/docker-compose > $(brew --prefix)/etc/bash_completion.d/docker-compose

No Linux

$ curl -L https://raw.githubusercontent.com/docker/compose/master/contrib/completion/bash/docker-compose > /etc/bash_completion.d/docker-compose

Completion do Docker Machine

O processo é praticamente o mesmo porém o docker-machine possui 3 arquivos de auto complete. Os arquivos estão disponíveis em https://github.com/docker/machine/tree/master/contrib/completion/bash . Reforçamos que sempre que fizer uma atualização é bom baixar novamente esse arquivo para refletir os comandos e parâmetros novos disponibilizados pelo Docker Machine.

Como dito anteriormente devemos colocá-los na pasta /etc/bash_completion.d/ se estivermos no Linux ou devemos acrescentar a pasta do homebrew antes se estivermos em um Mac OS X: $(brew --prefix)/etc/bash_completion.d.

Como são mais arquivos recomendo utilizarmos um loop para baixarmos todos em sequência utilizando apenas um comando.

No Mac OS X

machineVersion=`docker-machine --version | tr -ds ',' ' ' | awk 'NR==1{print $(3)}'`
files=(docker-machine docker-machine-wrapper docker-machine-prompt)
for file in "${files[@]}"; do
  curl -L https://raw.githubusercontent.com/docker/machine/v$machineVersion/contrib/completion/bash/$file.bash > `brew --prefix`/etc/bash_completion.d/$file
done
unset machineVersion

No Linux

machineVersion=`docker-machine --version | tr -ds ',' ' ' | awk 'NR==1{print $(3)}'`
files=(docker-machine docker-machine-wrapper docker-machine-prompt)
for file in "${files[@]}"; do
  curl -L https://raw.githubusercontent.com/docker/machine/v$machineVersion/contrib/completion/bash/$file.bash > /etc/bash_completion.d/$file
done
unset machineVersion

Considerações

Versões diferentes

Se você utilizar alguma versão específica de uma dessas ferramentas basta baixar os arquivos da pasta correspondente.

Por exemplo o docker engine, da maneira que mostramos vamos pegar o arquivo que está na branch master, atualmente versão 1.12.1, para pegar na versão 1.11.0 por exemplo o arquivo fica em https://github.com/docker/docker/blob/v1.11.0/contrib/completion/bash/docker

Utilizo outro shell

O Docker disponibiliza alguns arquivos de completion para outros shells. O Docker Engine disponibiliza bash, zsh, fish e powershell como podemos ver em https://github.com/docker/docker/tree/master/contrib/completion .

O Docker Compose e o Docker Machine disponibilizam apenas para bash e zsh como vemos nas urls https://github.com/docker/compose/tree/master/contrib/completion e https://github.com/docker/machine/tree/master/contrib/completion .

Demo

Segue um demo de como instalar o bash completion para o docker, para o docker-compose e para o docker-machine e como utilizá-los no Mac OS X.

É isso ae, curtiu, use, comente, compartilhe e contribua. Não curtiu, também comente e participe.

Abç

Muitas pessoas perguntam o que devem estudar ou quais cursos devem fazer para entrar de cabeça no mundo DevOps.

Não é uma resposta fácil, mas tenho algumas indicações para ajudar quem está começando.

1. Vídeos

10 Deploys per day at Flickr

Esse palestra foi a ignição que faltava para a criação do movimento/cultura DevOps em 2009.

https://www.youtube.com/watch?v=LdOe18KhtT4

Entenda as origens DevOps

Vídeo rápido de Damon Edwards (devopsdays core member) acerca das origens do movimento, recomendo.

https://www.youtube.com/watch?v=o7-IuYS0iSE

What is DevOps? - In Simple English

Vídeo curtinho do rackspace que também ajuda.

https://www.youtube.com/watch?v=_I94-tJlovg

DevOpsConf - DevOps State of the Union (John Willis)

Palestra do John Willis (devopsdays core member) na DevOpsCon 2015 sobre o estado do DevOps após 5 anos de seu surgimento.

https://www.youtube.com/watch?v=8rM8lYaMVBE

Five Years of DevOps (Patrick Debois)

Patrick Debois o criador do DevOpsDays e do termo DevOps fala o que achou dos últimos 5 anos de DevOps.

https://www.youtube.com/watch?v=uRMV6tT_mu0

2. Acrônimos

Entenda o que é CAMS

http://devopsdictionary.com/wiki/CAMS

Entenda o que é CALMS

http://whatis.techtarget.com/definition/CALMS

Entenda o que é ICE

http://radar.oreilly.com/2015/01/devops-keeps-it-cool-with-ice.html

Entenda o que é DevSecOps

 http://www.devsecops.org/blog/2015/2/15/what-is-devsecops    

3. Roteiro de estudos

Essa sugestão de estudos é baseada na estrutura CAMS do Willis e Edwards.

3.1 Cultura

• Estude a metodologia ágil de desenvovlimento
• Estude metodologias ágeis em geral
• Estude Scrum
• Estude Kanban
• Estude Lean
• Entenda o que é uma cultura de colaboração e feedback.

Faça um exercicio e tente enxergar os principais problemas culturais do seu time/organização e encontre uma forma corrigir tais problemas adaptando esses métodos.

3.2 Automação

• Estude virtualização
• Estude cloud computing
• Estude Mark Burgess e gerência de configurações
• Estude infraestrutura como código
• Conheça pelo menos duas ferramentas de Gerência de Configuração (CFEngine e Puppet)
• Conheça pelo menos duas ferramentas de Orquestração (Fabric e Ansible)
• Entenda o que é VCS (Version Control System)
• Estude GIT pra valer
• Estude workflows de desenvolvimento usando GIT (olhe os projetos opensource)
• Estude Continuous Integration
• Estude Continuous Delivery
• Estude Continious Deployment
• Estude TDD/BDD/ATDD
• Estude Load Testing
• Estude Stress Testing
• Estude Security Testing
• Estude Containers e Docker
• Estude Microservicos
• Estude ferramentas para fazer provisionamento automatizado
• Estude ferramentas de autoserviço
• Estude sistemas Unix e Linux
• Estude networking
• Estude e domine pelo menos 2 linguagens interpretadas (Ruby e Python)
• Conheça pelo menos 1 stack de cada linguagem
• Estude a linguagem shell

Labs sugeridos

• Tente subir uma stack full de automação (ex. puppet)
  • Tente automatizar confs simples do OS (ex. centos)
  • Tente automatizar a instalacao e configuracao de um APP (ex. apache)
• Tente provisionar VMs ou Containers de forma automatizada via autoserviço
• Tente construir um pipeline de entrega
  • Indo desde o commit, passando por build, testes até o deploy em vm e container

3.3 Avaliação/Métricas

• Entenda o que são métricas e pq são importantes
• Estude real-time-metrics
• Estude ferramentas APM
• Conheca bem pelo menos duas ferramentas de monitoramento (Nagios/Zabbix)
• Estude algum stack para tratamento de logs (ELK)
• Estude algum stack para coleta e armazenamento métricas (Collectd/Statsd/Graphite/Graphana)

Labs sugeridos

• Tente subir uma stack full de gestao de logs (ex. ELK)
  • Coloque diversos APPs para jogar dados lá
• Tente subir um stack full de gestao de dados
  • Gere dados, colete, armazene e visualize com essa stack

3.4 Compartilhamento

• Entenda a cultura de dividir responsabilidades
• Entenda a cultura Blameless
• Aprenda a compartilhar ferramentas entre todos os times
• Aprenda a compartilhar código entre todos os times
• Aprenda a compartilhar informações e dados
• Procure sempre melhorar o processo de comunicação
• Entenda como funcionam times de produtos
• Ofereça feedback constante entre os times
• Volte pra cultura e reinicie o ciclo até aqui
• Entenda e pratique Dojos
• Entenda os Hackerspaces
• Entenda os Hackatons

---

Cada eixo desse do roteiro de estudos tem cursos disponíveis no mercado, documentação farta online, artigos variados na rede.

Evite procurar por uma formação DevOps no mercado, o ideal é que você mesmo crie um roteiro de estudos.

Se encontrar alguma formação DevOps no mercado, fique alerta, tome muito cuidado para não ser uma empresa inventando algo só para faturar em cima da Buzzword DevOps, não invista seu dinheiro nesses cursos mágicos, como voce viu DevOps é algo amplo, difícil de colocar em um curso de 24 ou 40 horas, procure cursos especializados em centros reconhecidos ou oficiais, vá passando um assunto por vez, um curso por vez se você for da linha dos cursos, se for da linha da autodidaxia, mergulhe nas comunidades, leia, pergunte, compartilhe e aprenda junto conosco.

Coloquei esse guia no GitLab para receber contribs, mande PRs quando quiser.

• https://gitlab.com/gutocarvalho/devops-tips

Agora é começar os estudos, divirta-se!

[s]
Guto

Mercado Livre inaugura nova sede de R$ 105 milhões em São Paulo.

Post original por Jeff Barr | em 11 agosto 2016

Lançamos o Elastic Load Balancing (ELB) para AWS, na primavera de 2009 (veja New Features for Amazon EC2: Elastic Load Balancing, Auto Scaling, and Amazon CloudWatch para ver o quão longe a AWS tem ido desde então). O Elastic Load Balancing tornou-se um componente de arquitetura fundamental para muitas aplicações executadas na AWS. Em conjunto com o Auto Scaling, o Elastic Load Balancing simplifica a tarefa de construção de aplicações que podem escalar para cima e para baixo, mantendo uma alta disponibilidade.

No Nível

Per o modelo OSI bem conhecido, balanceadores de carga geralmente executados na camada 4 (transporte) ou na camada 7 (aplicação).

Um balanceador de carga de camada 4 funciona no nível de protocolo de rede e não olha para dentro dos pacotes de rede reais, mantendo as especificidades de HTTP e HTTPS desconhecidas. Em outras palavras, ele equilibra a carga sem necessariamente saber muita coisa sobre ela.

O balanceador de carga de camada 7 é mais sofisticado e mais poderoso. Ele inspeciona os pacotes, tem acesso aos cabeçalhos HTTP e HTTPS, e (munido de mais informações) pode fazer um trabalho mais inteligente de espalhar a carga para fora do alvo.

Application Load Balancing para AWS

Hoje estamos lançando a nova opção Application Load Balancer do ELB. Esta opção é executada na camada 7 e suporta algumas características avançadas. A opção original (agora chamado de Classic Load Balancer) ainda está disponível para você e continua a oferecer as funcionalidades das camadas 4 e 7.

O Application Load Balancers suporta roteamento baseado em conteúdo e suporte a aplicativos que são executados em containers. Eles suportam dois protocolos padrão da indústria (WebSocket e HTTP/2) e também proporcionam visibilidade adicional para a saúde das instâncias alvo e containers. Sites e aplicativos móveis, executando em containers ou em instâncias EC2, irã se beneficiar da utilização do Application Load Balancers.

Vamos dar uma olhada em cada um desses recursos e, em seguida, criar nos mesmos um novo Application Load Balancer!

Roteamento baseado em conteúdo

Um Application Load Balancer tem acesso a cabeçalhos HTTP e permite encaminhar as solicitações para diferentes serviços de back-end em conformidade. Por exemplo, você pode querer enviar solicitações que incluem /api no caminho de URL a um grupo de servidores (que nós chamamos de grupos-alvo) e os pedidos que incluem /mobile para outros. Encaminhamento de solicitações desta forma permite construir aplicações que são compostos de vários microservices que podem rodar e ser dimensionados de forma independente.

Como você verá em um momento, cada Application Load Balancer permite definir até 10 regras com base em URL para encaminhar pedidos de grupos-alvo. Ao longo do tempo, pretendemos dar-lhe acesso a outros métodos de encaminhamento.

Suporte para Aplicações baseados em Container

Muitos clientes da AWS estão empacotando suas microservices em recipientes e hospedá-los no Amazon EC2 Container Service. Isso permite que uma única instância EC2 execute um ou mais serviços, mas pode apresentar alguns desafios interessantes para carga tradicional equilíbrio no que diz respeito aos controlos de mapeamento de portas e de saúde.

O Application Load Balancer reconhece e suporta aplicações baseadas em containers. Ele permite que uma instância hospede vários containers que conversam com várias portas do mesmo grupo alvo e, também, executa exames de saúde refinados no nível de porta.

Métricas melhores

O Application Load Balancers pode executar e informar sobre exames de saúde em uma base por porta. Os exames de saúde podem especificar um intervalo de respostas HTTP aceitáveis, e são acompanhados por códigos de erro detalhados.

Como um subproduto do roteamento baseado em conteúdo, você também tem a oportunidade de coletar métricas sobre cada um de seus microservices. Este é um efeito colateral muito bom; cada um dos microservices pode ser executado em seu próprio grupo-alvo, em um conjunto específico de instâncias de EC2. Esta maior visibilidade lhe permitirá fazer um trabalho melhor de escalar para cima e para baixo em resposta à carga em serviços individuais.

O Application Load Balancer oferece várias métricas novas do CloudWatch incluindo tráfego total (em GB), o número de conexões ativas e a taxa de conexão por hora.

Suporte para Protocolos e cargas de trabalho adicionais

O Application Load Balancer suporta dois protocolos adicionais: WebSocket e HTTP/2.

O WebSocket permite configurar conexões TCP de longa data entre o cliente e o servidor. Esta é uma alternativa mais eficiente para o método old-school que envolveu conexões HTTP que foram realizadas abertas com uma “pulsação” por um longo período de tempo. O WebSocket é ótimo para dispositivos móveis e pode ser usado para entregar cotações de ações, resultados esportivos e outros dados dinâmicos, minimizando o consumo de energia. O ALB fornece suporte nativo para WebSocket através dos protocolos ws:// e wss://.

O HTTP/2 é uma melhoria significativa do protocolo original HTTP 1.1. O novo recurso do protocolo suporta pedidos multiplexados através de uma única conexão. Isto reduz o tráfego da rede, tal como a natureza binária do protocolo.

O Application Load Balancer é projetado para lidar com streaming, em tempo real e com as cargas de trabalho WebSocket de forma otimizada. Em vez de bufferizar os pedidos e as respostas, ele lida com eles na forma de streaming. Isso reduz a latência e aumenta o desempenho percebido de sua aplicação.

Criando um ALB

Vamos criar e configurar um Application Load Balancer para processar algum tráfego!

O Console do Elastic Load Balancing permite criar qualquer tipo de balanceador de carga:

Eu clico em Application load balancer, digito um nome (MyALB) e escolho internet-facing. Então eu adiciono um ouvinte HTTPS:

Na mesma tela, eu escolho o meu VPC (este é um recurso VPC-only) e uma sub-rede em cada Zona de disponibilidade desejada, marco o meu Application Load Balancer, e prossigo para Configure Security Settings:

Uma vez que eu criei um ouvinte HTTPS, meu Application Load Balancer precisa de um certificado. Eu posso escolher um certificado existente que já está em IAM ou AWS Certificate Manager (ACM), fazer upload de um certificado local, ou solicitar um novo:

Seguindo em frente, eu monto o meu grupo de segurança. Neste caso, eu decidi criar um novo. Eu poderia ter usado um dos meus grupos de segurança EC2 ou VPC existentes com a mesma facilidade:

O próximo passo é criar o meu primeiro grupo-alvo (main) e configurar as respectivas verificações de saúde (Vou usar as configurações padrão):

Agora estou pronto para escolher os alvos – o conjunto de instâncias EC2 que receberão o tráfego através do meu Application Load Balancer. Aqui, eu escolhi os alvos que estão escutando na porta 80:

O último passo é rever minhas escolhas e para Create o meu ALB:

Depois que eu clicar em Create o Application Load Balancer é provisionado e se torna ativo dentro de um minuto ou algo assim:

Eu posso criar grupos-alvo adicionais:

E então eu posso adicionar uma nova regra que encaminha solicitações /api para o alvo:

O Application Load Balancers trabalha com vários serviços da AWS, incluindo Auto Scaling, Amazon ECS, AWS CloudFormation, AWS CodeDeploy e AWS Certificate Manager (ACM). O suporte para outros serviços está em obras.

Moving on Up

Se você está usando um balanceador de carga clássico e gostaria de migrar para um Application Load Balancer, dê uma olhada em nosso novo Load Balancer Copy Utility. Esta ferramenta Python vai ajudar você a criar um Application Load Balancer com a mesma configuração como um balanceador de carga clássico existente. Ele também pode registrar suas instâncias EC2 existentes com o novo balanceador de carga.

Disponibilidade e Preços

O Application Load Balancer já está disponível em todas as regiões comerciais da AWS e você já pode começar a usá-lo!

A taxa horária para o uso de um Application Load Balancer é 10% menor do que o custo de um Classic Load Balancer.

Quando você usa um Application Load Balancer, você será cobrado por hora e para o uso de unidades de capacidade do Load Balancer, também conhecido como LCU. Um LCU mede o número de novas conexões por segundo, o número de conexões ativas e transferência de dados. Medimos em todas as três dimensões, mas a cobrança é feita com base na mais alta. Um LCU é suficiente para suportar qualquer uma:

• 25 conexões/segundo com um certificado de 2 KB, 3.000 conexões ativas e 2,22 Mbps de transferência de dados ou
• 5 conexões/segundo com um certificado de 4 KB, 3.000 conexões ativas e 2,22 Mbps de transferência de dados.

A cobrança para uso LCU é fracionada, e é cobrado em US $ 0,008 por LCU por hora. Com base em nossos cálculos, acreditamos que praticamente todos os nossos clientes podem obter uma redução líquida em seus custos de balanceamento de carga, passando de um Classic Load Balancer para um Application Load Balancer.

Deixe suas dúvidas e/ou comentários aqui ou escreva diretamente para o nosso colega Jeff Barr (em inglês).

Os cientistas anunciaram a descoberta do que pode ser o fóssil mais antigo do mundo, ou seja, uma forma de vida que existiu há 3,7 bilhões de anos. Na época, o céu da Terra ainda era laranja e os oceanos verdes.

O fóssil foi encontrado em uma parte recém-derretida da Groelândia, onde cientistas australianos encontraram uma estrutura abandonada de uma comunidade de micróbios que viveu em um antigo fundo do mar. O estudo foi publicado na quarta-feira (30) na revista Nature.

Continue a leitura...

Cientistas do SETI (Search for Extraterrestrial Intelligence), revelaram na noite de segunda-feira (29), a descoberta de um sinal vindo do espaço. O estranho sinal, para muitos especialistas da área, pode ter vindo de uma civilização alienígena.

Sinal de rádio captado por cientistas pode ter origem alienígena.

 

Para comprovar a real origem do sinal é necessário ainda que os cientistas investiguem a procedência, porém, a hipótese de ser originado de outros planetas ainda não está descartada.

Continue a leitura...

E logo depois pedem desculpas pelo vacilo. As vezes a vida é bonita.

Não apenas pediu perdão como também expôs todos os problemas da vida dele. Ser preso as vezes faz bem pra pessoa.

A pessoa pode estar morta, mas o caixão é rebaixado, com neon e sonzão. É pra chegar no inferno bombando…

– PERDEU MANO, PERDEU, PASSA TUDO
– Perdão sr. ladrão, poderia me esclarecer por favor o que eu perdi?
– PASSA LOGO AS COISA TUDO
– Poderia ser mais específico? O que quer que eu passe?
– PASSA O CELULAR
– Você quer meu aparelho ou meu número?

O bandido se irritou e foi embora. Obrigado, Doutor Segurança.