One place for hosting & domains


      How To Install Software on Kubernetes Clusters with the Helm 3 Package Manager


      Helm is a package manager for Kubernetes that allows developers and operators to more easily configure and deploy applications on Kubernetes clusters.

      In this tutorial, you will set up Helm 3 and use it to install, reconfigure, rollback, and delete an instance of the Kubernetes Dashboard application. The dashboard is an official web-based Kubernetes GUI.

      For a conceptual overview of Helm and its packaging ecosystem, please read our article, An Introduction to Helm.


      For this tutorial you will need:

      • A Kubernetes cluster with role-based access control (RBAC) enabled. Helm 3.1 supports clusters from versions 1.14 to 1.17. For further information check the Helm releases page.
      • The kubectl command-line tool installed on your local machine, configured to connect to your cluster. You can read more about installing kubectl in the official documentation.

        You can test your connectivity with the following command:

        If you see no errors, you’re connected to the cluster. If you access multiple clusters with kubectl, be sure to verify that you’ve selected the correct cluster context:

        • kubectl config get-contexts


        CURRENT NAME CLUSTER AUTHINFO NAMESPACE * do-fra1-helm3-example do-fra1-helm3-example do-fra1-helm3-example-admin

        In this example the asterisk (*) indicates that we are connected to the do-fra1-helm3-example cluster. To switch clusters run:

        • kubectl config use-context context-name

      When you are connected to the correct cluster, continue to Step 1 to begin installing Helm.

      Step 1 — Installing Helm

      First, you’ll install the helm command-line utility on your local machine. Helm provides a script that handles the installation process on MacOS, Windows, or Linux.

      Change to a writable directory and download the script from Helm’s GitHub repository:

      • cd /tmp
      • curl -fsSL -o

      Make the script executable with chmod:

      You can use your favorite text editor to open the script and inspect it to make sure it’s safe. When you are satisfied, run it:

      You may be prompted for your password. Provide it and press ENTER to continue.

      The output will look like this:


      Downloading Preparing to install helm into /usr/local/bin helm installed into /usr/local/bin/helm

      Now that you’ve got Helm installed, you’re ready to use Helm to install your first chart.

      Step 2 — Installing a Helm Chart

      Helm software packages are called charts. There is a curated chart repository called stable, mostly consisting of common charts, which you can see in their GitHub repo. Helm does not come preconfigured for it, so you’ll need to manually add it. Then, as an example, you are going to install the Kubernetes Dashboard.

      Add the stable repo by running:

      • helm repo add stable

      The output will be:


      "stable" has been added to your repositories

      Then, use helm to install the kubernetes-dashboard package from the stable repo:

      • helm install dashboard-demo stable/kubernetes-dashboard --set rbac.clusterAdminRole=true

      The --set parameter lets you to customize chart variables, which the chart exposes to allow you to customize its configuration. Here, you set the rbac.clusterAdminRole variable to true to grant the Kubernetes Dashboard access to your whole cluster.

      The output will look like:


      NAME: dashboard-demo LAST DEPLOYED: Tue Mar 31 15:04:19 2020 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: ...

      Notice the NAME line, highlighted in the above example output. In this case, you specified the name dashboard-demo. This is the name of the release. A Helm release is a single deployment of one chart with a specific configuration. You can deploy multiple releases of the same chart, each with its own configuration.

      You can list all the releases in the cluster:

      The output will be similar to this:


      NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION dashboard-demo default 1 2020-03-31 15:04:19.324774799 +0000 UTC deployed kubernetes-dashboard-1.10.1 1.10.1

      You can now use kubectl to verify that a new service has been deployed on the cluster:

      The output will look like this:


      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE dashboard-demo-kubernetes-dashboard ClusterIP <none> 443/TCP 4m44s kubernetes ClusterIP <none> 443/TCP 19m

      Notice that by default, the service name corresponding to the release is a combination of the Helm release name and the chart name.

      Now that you’ve deployed the application, you’ll use Helm to change its configuration and update the deployment.

      Step 3 — Updating a Release

      The helm upgrade command can be used to upgrade a release with a new or updated chart, or update its configuration options (variables).

      You’re going to make a simple change to the dashboard-demo release to demonstrate the update and rollback process: you’ll update the name of the dashboard service to just kubernetes-dashboard, instead of dashboard-demo-kubernetes-dashboard.

      The kubernetes-dashboard chart provides a fullnameOverride configuration option to control the service name. To rename the release, run helm upgrade with this option set:

      • helm upgrade dashboard-demo stable/kubernetes-dashboard --set fullnameOverride="kubernetes-dashboard" --reuse-values

      By passing in the --reuse-values argument, you make sure that chart variables you’ve previously set do not get reset by the upgrade process.

      You’ll see output similar to the initial helm install step.

      Check if your Kubernetes services reflect the updated values:

      The output will look like the following:


      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP <none> 443/TCP 38m kubernetes-dashboard ClusterIP <none> 443/TCP 8s

      Notice that the service name has been updated to the new value.

      Note: At this point you may want to actually load the Kubernetes Dashboard in your browser and check it out. To do so, first run the following command:

      This creates a proxy that lets you access remote cluster resources from your local computer. Based on the previous instructions, your dashboard service is named kubernetes-dashboard and it’s running in the default namespace. You may now access the dashboard at the following URL:


      Instructions for actually using the dashboard are out of scope for this tutorial, but you can read the official Kubernetes Dashboard docs for more information.

      Next, you’ll have a look at Helm’s ability to roll back and delete releases.

      Step 4 — Rolling Back and Deleting a Release

      When you updated the dashboard-demo release in the previous step, you created a second revision of the release. Helm retains all the details of previous releases in case you need to roll back to a prior configuration or chart.

      Use helm list to inspect the release again:

      You’ll see the following output:


      NAME REVISION UPDATED STATUS CHART NAMESPACE dashboard-demo 2 Wed Aug 8 20:13:15 2018 DEPLOYED kubernetes-dashboard-0.7.1 default

      The REVISION column tells you that this is now the second revision.

      Use helm rollback to roll back to the first revision:

      • helm rollback dashboard-demo 1

      You should see the following output, indicating that the rollback succeeded:


      Rollback was a success! Happy Helming!

      At this point, if you run kubectl get services again, you will notice that the service name has changed back to its previous value. Helm has re-deployed the application with revision 1’s configuration.

      Helm releases can be deleted with the helm delete command:

      • helm delete dashboard-demo

      The output will be:


      release "dashboard-demo" uninstalled

      You can try listing Helm releases:

      You’ll see that there are none:



      Now the release has been truly deleted, and you can reuse the release name.


      In this tutorial, you installed the helm command-line tool and explored installing, upgrading, rolling back, and deleting Helm charts and releases by managing the kubernetes-dashboard chart.

      For more information about Helm and Helm charts, please see the official Helm documentation.

      Source link

      How To Package and Publish a Snap Application on Ubuntu 18.04

      The author selected the Electronic Frontier Foundation to receive a donation as part of the Write for DOnations program.


      One of the largest challenges in application development is the final step of distributing the finished product to your users or customers. Many existing application deployment methodologies lack user-friendliness and security, or do not provide methods for automatically updating an application once it has been installed.

      Snap is a modern application packaging format with powerful sandboxing and security features, including file system isolation, automatic updates, and integrated dependency management. Snap applications, known as Snaps, can be downloaded and installed using a command-line program, much like apt or yum. Ubuntu comes with Snap pre-installed, meaning that there is a wide audience for Snap applications.

      In this tutorial, you will create a Snap application and publish it on the Snap Store.


      To complete this tutorial, you will need:

      • One Ubuntu 18.04 server set up by following the Initial Server Setup with Ubuntu 18.04, including a sudo non-root user.

      • An application that you wish to package and release as a Snap. This may be a complex application that you created, a common open-source project, or a simple “Hello, world!” program. If you don’t already have an application, Step 1 of this tutorial will cover how you can create a Hello World program in Go.

      • An account on the Snapcraft Developer Dashboard.

      Once you have these ready, log in to your server as your non-root user to begin.

      Step 1 — Getting Your Application Ready for Packaging

      Firstly, you’ll prepare your application for packaging as a Snap application by ensuring that everything required is present in a single directory.

      Start by creating a new directory for your Snap and moving into it:

      • mkdir ~/your-snap
      • cd ~/your-snap

      Next, if you already have an application, put a complete copy of the source code for your application into the directory that you just created. The process here will vary significantly depending on the exact application that you’re packaging, however in the case that the source code is stored in a Git repository, you can git init a repository in the directory and pull down all of the relevant code.

      If you don’t yet have an application that you’d like to package, you may create a “Hello World” program to use instead. If you would like more context on writing this program with Go, check out the How to Write Your First Program in Go tutorial.

      You can do this by first creating a new Go file and opening it using your preferred text editor:

      Next, add the following code to the file:


      package main
      import "fmt"
      func main() {
        fmt.Println("Hello, world!")

      Then save and exit the file.

      If you don’t have Go installed, you can install it using the following command:

      • sudo apt install golang-go

      Once Go is installed, you can run your new program to check that it is working:

      You’ll see the following output:


      Hello, world!

      You’ve prepared your application for packaging as a Snap. Next, you will install the software required to begin the packaging process.

      Step 2 — Installing Snapcraft

      In this step, you’ll download and install Snapcraft, which is the name of the official Snap application packaging tool. Snapcraft is available from the Snap Store, which is built into Ubuntu by default. This means that you can install Snapcraft from the command-line using the snap command.

      The snap command is equivalent to the apt command, but you can use it to install software from the Snap Store, rather than packages from the Apt repositories.

      In order to install Snapcraft, run the following command:

      • sudo snap install snapcraft --classic

      You use the --classic command argument so that Snapcraft installs without the strict sandboxing features that Snaps normally use. Snapcraft requires this argument as it needs more privileged access to your system to reliably package applications.

      Once you’ve installed Snapcraft, you’ll see the following:


      snapcraft 3.9.8 from Canonical✓ installed

      Finally, you can double-check the Snapcraft installation by running:

      This will display something similar to:


      snapcraft, version 3.9.8

      Now that you’ve installed Snapcraft, you can begin to define the configuration and metadata for your Snap application.

      In this step, you will begin to define the configuration, structure, and metadata for your Snap application.

      Begin by ensuring that you are still working in your Snap application directory:

      Next, create and edit the snapcraft.yaml file using your preferred text editor:

      You’ll use the snapcraft.yaml file to store all of the configuration for your Snap application, including the name, description, and version, as well as settings related to dependency management and sandboxing.

      Begin by defining the name, summary, description, and version number for your application:


      name: your-snap
      summary: A summary of your application in 78 characters or less.
      description: |
        A detailed description of your application.
        The description can have multiple lines.
      version: '1.0'

      The name of your Snap needs to be unique if you wish to publish it on the Snap Store—search for other applications with the same name to make sure that it isn’t already taken.

      Next, you can define the command(s) that you wish to associate with your application. This will allow your Snap to be used directly from the Bash command-line as a normal command.

      Add the following to your snapcraft.yaml file:


      . . .
          command: your-snap

      your-snap-command is the name of the command that you want to define. For example, you may wish to use the command helloworld to run your Hello World program.

      You use command: your-snap to tell Snapcraft what to do when the application command is run. In the case of the Hello World program, you would use the value helloworld to reference the helloworld.go file, which will allow Snapcraft to run your program successfully.

      This results in the following example configuration:


          command: helloworld

      If the command name matches the Snap name exactly, you’ll be able to run it directly from the command-line. If the command does not match the Snap name, the command will be automatically prefixed with the name of the Snap. For example, helloworld.command1.

      Finally, you can define the parts that make up your Snap application. Snap applications are made up of multiple parts, which are all of the components that make up your application. In many cases, there is only one part, which is the application itself.

      Each part has an associated plugin. For example, for components of your application written in Ruby, the ruby plugin is used, and for components written in Go, the go plugin is used.

      You can use the Snapcraft list-plugins command to identify the correct plugin(s) for your application:

      This will output a list similar to the following:


      ant catkin-tools conda dump gradle make nil python rust autotools cmake crystal go kbuild maven nodejs qmake scons catkin colcon dotnet godeps kernel meson plainbox-provider ruby waf

      The most common plugins are those for common programming languages, such as Go, Rust, Ruby, or Python.

      Once you have identified the correct plugins for your application, you can begin to add the parts configuration to your snapcraft.yaml file:


      . . .
          plugin: plugin-name
          source: .

      You use the source configuration parameter to specify the relative path to the source code for your application. Usually this will be the same directory as the snapcraft.yaml file itself, so the source value is a single dot (.).

      Note: If your application component has any dependencies that are required for either building or running it, you can specify these using the build-packages and stage-packages attributes. The specified dependency names will then be automatically fetched from the default package manager for your system.

      For example:


        plugin: plugin-name
        source: .
        - gcc
        - make
        - libcurl4

      Some Snapcraft plugins have their own specific options that may be required for your application, so it’s worthwhile reviewing the relevant manual pages for your plugin:

      • snapcraft help plugin-name

      In the case of Go applications, you would also specify the go-importpath. For the Hello World configuration, this results in the following example configuration:


          plugin: go
          source: .
          go-importpath: helloworld

      You can leave your snapcraft.yaml file open to add further configuration in the next step.

      You’ve defined the base configuration for your Snap application. Next, you’ll configure the security and sandboxing aspects of your application.

      Step 4 — Securing Your Snap Application

      Snap applications are designed to run within a sandboxed environment, so in this step you’ll configure sandboxing for your Snap. Firstly, you’ll need to enable sandboxing for your application, known within Snapcraft as confinement.

      Add the following to your snapcraft.yaml file:


      . . .
      confinement: strict

      This will enable sandboxing for your application, preventing it from accessing the internet, other running Snaps, or the host system itself. However, in most cases, applications do need to be able to communicate outside of their sandbox like when they need to access the internet or read/write to the file system.

      These permissions, known within Snapcraft as interfaces, can be granted to your Snap application using Plugs. Using Plugs, you can have fine-grain control over the sandboxing for your application, to give it the access that it requires and nothing more (principle of least privilege).

      The exact interfaces that are required will vary depending on your application. Some of the most common interfaces are:

      • audio-playback - Allows audio output/playing sounds.
      • audio-record - Allows audio input/recording.
      • camera - Allows access to connected webcams.
      • home - Allows access to non-hidden files within your home directory.
      • network - Allows access to the network/internet.
      • network-bind - Allows binding to ports to operate as a network service.
      • system-files - Allows access to the entire file system of the host machine.

      The full list of available interfaces can be found within the Snapcraft documentation under Supported Interfaces.

      Once you’ve identified all of the required interfaces for your application, you can begin to assign these to plugs within your snapcraft.yaml file.

      The following example configuration will allow the application to access the network and users’ home area:


      . . .
          interface: home
          interface: network

      Save and exit your file.

      The name of the Plug should be a descriptive name to help users identify the purpose of the Plug.

      You’ve enabled sandboxing for your Snap and configured some Plugs to grant limited access to system resources. Next you’ll finish building your Snap app.

      Step 5 — Building and Testing Your Snap Application

      Now that you’ve written all of the required configuration for your Snap, you can proceed with building it and testing the Snap package locally.

      If you’ve been following along using a Hello World program as your application, your complete snapcraft.yaml file will now look similar to the following:


      name: helloworld
      summary: A simple Hello World program.
      description: |
        A simple Hello World program written in Go.
        Packaged as a Snap application using Snapcraft.
      version: '1.0'
      confinement: strict
          command: helloworld
          plugin: go
          source: .
          go-importpath: helloworld
          interface: home
          interface: network

      In order to build your Snap application, run the snapcraft command from within the directory for your Snap:

      Snapcraft will then automatically launch a virtual machine (VM) and begin building your Snap. Once complete, Snapcraft will exit and you will see something similar to the following:


      Snapped your-snap_1.0_amd64.snap

      You can now install your Snap locally in order to check that it is working:

      • sudo snap install your-snap.snap --dangerous

      The --dangerous command argument is required as you are installing a local Snap that has not been signed.


      your-snap 1.0 installed

      Once the installation process is complete, you can then run your Snap using its associated command. For example:

      In the case of the example Hello World program, the following output would be:


      Hello, world!

      You can also view the sandboxing policy for your Snap to make sure that the assigned permissions have been properly granted:

      • snap connections your-snap

      This will output a list of Plugs and interfaces, similar to the following:


      snap connections your-snap Interface Plug Slot Notes home your-snap:your-snap-home :home - network your-snap:your-snap-network :network -

      In this step, you built your Snap and installed it locally to test that it is working. Next, you’ll publish your Snap on the Snap Store.

      Step 6 — Publishing Your Snap

      Now that you’ve built and tested your Snap application, it’s time to release it on the Snap Store.

      Begin by logging in to your Snap Developer account using the Snapcraft command-line application:

      Follow the prompts to enter your email address and password.

      Next, you need to register the name of the application on the Snap Store:

      • snapcraft register your-snap

      Once you’ve registered the Snap name, you can push the built Snap package to the store:

      • snapcraft push your-snap.snap

      You’ll see output similar to the following:


      Preparing to push 'your-snap_1.0_amd64.snap'. Install the review-tools from the Snap Store for enhanced checks before uploading this snap. Pushing 'your-snap_1.0_amd64.snap' [===================================================================================================] 100% Processing...| Ready to release! Revision 1 of 'your-snap' created.

      Each time you push to the Snap store, the revision number is incremented, starting at one. This is useful to help identify the various different builds of your Snap.

      Finally, you can release your Snap to the public:

      • snapcraft release your-snap revision-number channel

      If this is the first time you’ve pushed to the Snap Store, the revision number will be 1. You can also choose between releasing to the stable, candidate, beta, and edge channels, if you have multiple versions of your application at different stages of development.

      For example, the following command will release revision 1 of the Hello World Snap to the stable channel:

      • snapcraft release helloworld 1 stable

      You’ll see output similar to the following:


      Track Arch Channel Version Revision latest amd64 stable 1.0 1 candidate ^ ^ beta ^ ^ edge ^ ^ The 'stable' channel is now open.

      You can now search for your application on the Snap Store and install it on any of your devices.

      Snapcraft store with HelloWorld App displayed from search results

      In this final step, you uploaded your built Snap package to the Snap Store and released it to the public.


      In this article you configured and built a Snap application, and then released it to the public via the Snap Store. You now have the foundational knowledge required to maintain your application and building new ones.

      If you wish to explore Snaps further, you may wish to browse the full Snap Store. You may also wish to review the Snapcraft YAML Reference to understand more about it and identify additional attributes for your Snap configuration.

      Finally, if you’d like to investigate Snap development further, you may enjoy reading about and implementing Snap Hooks, which allow Snaps to dynamically react to system changes such as upgrades or security policy adjustments.

      Source link

      How To Install Software on Kubernetes Clusters with the Helm Package Manager


      O Helm é um gerenciador de pacotes para o Kubernetes que permite que os desenvolvedores e operadores configurem e implantem mais facilmente aplicativos nos clusters do Kubernetes.

      Neste tutorial, vamos configurar o Helm e usá-lo para instalar, reconfigurar, reverter e então excluir uma instância do aplicativo de painel do Kubernetes. O painel é uma GUI oficial do Kubernetes baseada em Web.

      Para uma visão conceitual do Helm e seu ecossistema de empacotamento, leia nosso artigo Uma introdução ao Helm.


      Para este tutorial, você precisará de:

      • Um cluster do Kubernetes 1.8+ com controle de acesso baseado na função (RBAC) habilitado
      • A ferramenta kubectl de linha de comando instalada em sua máquina local, configurada para se conectar ao seu cluster. Você pode ler mais sobre como instalar o kubectl na documentação oficial.

      Você pode testar sua conectividade com o seguinte comando:

      Se não houver erros, você está conectado ao cluster. Se acessar vários clusters com o kubectl, certifique-se de verificar se você selecionou o contexto de cluster correto:

      • kubectl config get-contexts


      CURRENT NAME CLUSTER AUTHINFO NAMESPACE * do-nyc1-k8s-example do-nyc1-k8s-example do-nyc1-k8s-example-admin docker-for-desktop docker-for-desktop-cluster docker-for-desktop

      Neste exemplo, o asterisco (*) indica que estamos conectados ao cluster do-nyc1-k8s-example. Para trocar os clusters execute:

      • kubectl config use-context context-name

      Quando estiver conectado ao cluster correto, continue para o Passo 1 para começar a instalar o Helm.

      Passo 1 — Como instalar o Helm

      Primeiro, vamos instalar o utilitário de linha de comando helm na nossa máquina local. O Helm fornece um script que lida com o processo de instalação no MacOS, Windows ou Linux.

      Mude para um diretório gravável e baixe o script do repositório do GitHub do Helm:

      • cd /tmp
      • curl >

      Crie o executável do script com o chmod:

      • chmod u+x

      Neste ponto, você pode usar seu editor de texto favorito para abrir o script e inspecioná-lo para garantir que ele está seguro. Quando estiver satisfeito, execute-o:

      Você pode ser solicitado a colocar sua senha. Digite ela e pressione ENTER.


      helm installed into /usr/local/bin/helm Run 'helm init' to configure helm.

      Em seguida, vamos concluir a instalação instalando alguns componentes do Helm no nosso cluster.

      Passo 2 — Como instalar o Tiller

      O Tiller é um companheiro do comando helm que é executado no seu cluster, recebendo comandos do helm e se comunicando diretamente com a API do Kubernetes para fazer o trabalho real de criar e excluir recursos. Para dar ao Tiller as permissões que ele precisa para ser executado no cluster, vamos fazer um recurso do Kubernetes, o serviceaccount.

      Nota: vamos ligar esse serviceaccount à função do cluster cluster-admin. Isso dará ao superusuário do serviço tiller acesso ao cluster e permitirá que ele instale todos os tipos de recurso em todos os namespaces. Isso é bom para explorar o Helm, mas você pode querer uma configuração mais fechada para um cluster do Kubernetes de produção.

      Por favor, consulte a documentação oficial do Helm RBAC para mais informações sobre a configuração de diferentes cenários RBAC para o Tiller.

      Crie o tiller serviceaccount:

      • kubectl -n kube-system create serviceaccount tiller

      Em seguida, vincule o tiller serviceaccount à função cluster-admin:

      • kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller

      Agora, podemos executar o helm init, que instala o Tiller no nosso cluster, junto com algumas tarefas de organização local, como baixar os detalhes do repositório stable:

      • helm init --service-account tiller


      . . . Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster. Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy. For more information on securing your installation see: Happy Helming!

      Para verificar se o Tiller está funcionando, liste os módulos no namespace kube-system:

      • kubectl get pods --namespace kube-system


      NAME READY STATUS RESTARTS AGE . . . kube-dns-64f766c69c-rm9tz 3/3 Running 0 22m kube-proxy-worker-5884 1/1 Running 1 21m kube-proxy-worker-5885 1/1 Running 1 21m kubernetes-dashboard-7dd4fc69c8-c4gwk 1/1 Running 0 22m tiller-deploy-5c688d5f9b-lccsk 1/1 Running 0 40s

      O nome do módulo do Tiller começa com o prefixo tiller-deploy-.

      Agora que instalamos ambos os componentes do Helm, estamos prontos para usar o helm para instalar nosso primeiro aplicativo.

      Passo 3 — Instalando um chart do Helm

      Os pacotes de software do Helm são chamados de charts. O Helm vem pré-configurado com um repositório de charts coletados chama do stable. Você pode verificar os gráficos disponíveis nos seus repositórios do GitHub. Vamos instalar o Painel do Kubernetes como um exemplo.

      Use o helm para instalar o pacote kubernetes-dashboard do repositório stable:

      • helm install stable/kubernetes-dashboard --name dashboard-demo


      NAME: dashboard-demo LAST DEPLOYED: Wed Aug 8 20:11:07 2018 NAMESPACE: default STATUS: DEPLOYED . . .

      Observe a linha NAME, em destaque no exemplo de resultado acima. Neste caso, especificamos o nome dashboard-demo. Este é o nome do nosso release. Um release do Helm é uma única implantação de um chart com uma configuração específica. Você pode implantar vários releases do mesmo chart, tendo cada um sua própria configuração.

      Se não especificar seu próprio nome de release usando --name, o Helm criará um nome aleatório para você.

      Podemos pedir ao Helm uma lista de releases neste cluster:


      NAME REVISION UPDATED STATUS CHART NAMESPACE dashboard-demo 1 Wed Aug 8 20:11:11 2018 DEPLOYED kubernetes-dashboard-0.7.1 default

      Agora, podemos usar o kubectl para verificar se um novo serviço foi implantado no cluster:


      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE dashboard-demo-kubernetes-dashboard ClusterIP <none> 443/TCP 51s kubernetes ClusterIP <none> 443/TCP 34m

      Note que por padrão, o nome de serviço correspondente ao nosso release é uma combinação do nome de release do Helm e o nome do chart.

      Agora que implantamos o aplicativo, vamos usar o Helm para alterar sua configuração e atualizar a implantação.

      Passo 4 — Atualizando um release

      O comando helm upgrade pode ser usado para atualizar um release com um chart novo ou atualizado, ou atualizar as suas opções de configuração.

      Vamos fazer uma alteração simples no nosso release dashboard-demo para demonstrar o processo de atualização e reversão: atualizaremos o nome do serviço do painel para apenas dashboard, em vez de dashboard-demo-kubernetes-dashboard.

      O chart kubernetes-dashboard fornece uma opção de configuração fullnameOverride para controlar o nome do serviço. Vamos executar o helm upgrade com esta opção definida:

      • helm upgrade dashboard-demo stable/kubernetes-dashboard --set fullnameOverride="dashboard"

      Você verá um resultado similar ao passo inicial helm install.

      Verifique se seus serviços do Kubernetes refletem os valores atualizados:


      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP <none> 443/TCP 36m dashboard ClusterIP <none> 443/TCP 40s

      Nosso nome de serviço foi atualizado para o novo valor.

      Nota: neste ponto, você pode carregar o Painel do Kubernetes no seu navegador e verificá-lo. Para fazer isso, execute primeiro o seguinte comando:

      Isso cria um proxy que permite que você acesse recursos de cluster remotos do seu computador local. Baseado nas instruções anteriores, seu serviço de dashboard é chamado kubernetes-dashboard e ele está funcionando no namespace default. Agora, você pode acessar o painel no seguinte URL:


      Se necessário, substitua seu próprio nome de serviço e namespace pelas porções destacadas. As instruções para de fato usar o painel estão fora do escopo deste tutorial, mas você pode ler os docs oficiais do Painel do Kubernetes para mais informações.

      Em seguida, vamos ver a capacidade do Helm para reverter releases.

      Passo 5 — Revertendo um release

      Quando atualizamos nosso release dashboard-demo no passo anterior, criamos uma segunda revision do release. O Helm retém todos os detalhes dos release anteriores caso precise reverter para uma configuração ou chart prévia.

      Use o helm list para verificar o release novamente:


      NAME REVISION UPDATED STATUS CHART NAMESPACE dashboard-demo 2 Wed Aug 8 20:13:15 2018 DEPLOYED kubernetes-dashboard-0.7.1 default

      A coluna REVISION nos diz que essa é agora a segunda revisão.

      Use o helm rollback para reverter para a primeira revisão:

      • helm rollback dashboard-demo 1

      Você deve ver o seguinte resultado, indicando que a reversão foi bem sucedida:


      Rollback was a success! Happy Helming!

      Neste ponto, caso execute o kubectl get services novamente, verá que o nome de serviço mudou para seu valor anterior. O Helm reimplantou o aplicativo com a configuração da revisão 1.

      Em seguida, vamos ver como excluir releases com o Helm.

      Passo 6 — Excluindo um release

      Os releases do Helm podem ser excluídos com o comando helm delete:

      • helm delete dashboard-demo


      release "dashboard-demo" deleted

      Embora o release tenha sido excluído e o aplicativo do painel não esteja mais em funcionamento, o Helm salva todas as informações de revisão caso queira reimplantar o release. Se você tentasse usar o helm install em um novo release dashboard-demo agora, receberia um erro:

      Error: a release named dashboard-demo already exists.

      Se você usar a flag --deleted para listar seus releases excluídos, verá que o release ainda está presente:


      NAME REVISION UPDATED STATUS CHART NAMESPACE dashboard-demo 3 Wed Aug 8 20:15:21 2018 DELETED kubernetes-dashboard-0.7.1 default

      Para realmente excluir o release e purgar todas as revisões antigas, utilize a flag --purge com o comando helm delete:

      • helm delete dashboard-demo --purge

      Agora, o release foi realmente excluído e você pode reutilizar seu nome.


      Neste tutorial, instalamos a ferramenta de linha de comando helm e seu serviço companheiro tiller. Também exploramos instalar, atualizar, reverter e excluir charts e releases do Helm.

      Para maiores informações sobre o Helm e charts do Helm, consulte a documentação oficial do Helm.

      Source link