github.com/SupersunnySea/draft@v0.16.0/docs/install-cloud.md (about) 1 # Cloud installations and Advanced Configuration 2 3 In certain situations, users are given a Kubernetes cluster with security constraints such as 4 5 - needing to push and pull container images to and from a remote or otherwise secured container registry 6 - only being able to deploy applications to a certain namespace 7 - running applications in an RBAC-enabled cluster 8 9 This document explains some of these situations as well as how it can be handled using draft. 10 11 ## Drafting in the Cloud 12 13 When using Draft with cloud-provided Kubernetes solutions like [Azure Container Service (AKS)](https://azure.microsoft.com/services/container-service/), [Google Kubernetes Engine (GKE)](https://cloud.google.com/kubernetes-engine/), or [Amazon EKS](https://aws.amazon.com/eks/), we need a way to distribute the built image across the cluster. A container registry allows all nodes in the Kubernetes cluster to pull the images we build using Draft, and we have a way for our local Docker daemon to distribute the built image. 14 15 For local use with Minikube, only the `eval $(minikube docker-env)` command is required to inform Draft to use the local registry. 16 17 For cloud registry services, like Azure Container Registry (ACR), Docker Hub, or other container registry services, two things are needed. 18 1. You need to tell Draft where the registry resides using the `draft config set registry` command, passing the registry's server URL (without the protocol scheme). 19 2. Unless there is a trust relationship between the cluster provider and the registry -- [as you can configure between the Azure Kubernetes Service (AKS) and the Azure Container Registry (ACR)](https://docs.microsoft.com/azure/container-registry/container-registry-auth-aks#grant-aks-access-to-acr) -- you'll need to either [add a container registry secret to your chart](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry) to pull the private image, or you can configure Draft to inject a secret for you for deployment using the login feature of your registry provider. 20 21 ## Drafting with ACR and AKS 22 23 Let's use Azure Container Registry (ACR) as an example registry, and use AKS as our Kubernetes service for this example. 24 25 REMEMBER: Kubernetes services like Azure Kubernetes Service (AKS) are automatically authorized to pull from container registries in the same resource group. If this is not the case, then please reread the [Drafting in the Cloud](#drafting-in-the-cloud) section. 26 27 For this example, we want to push images to our registry sitting at `myregistry.azurecr.io`, and pull those images down to the Kubernetes cluster from that same registry. To do that, we run 28 29 ```shell 30 $ draft config set registry myregistry.azurecr.io 31 ``` 32 33 This command tells Draft to push images to this container registry as well as to tell Kubernetes to pull images from this container registry. If you were using Docker Hub, for example, you would specify `docker.io/myregistry`. 34 35 We'll also need to log into the cluster to push images from our local docker daemon to the container registry: 36 37 ``` 38 $ az acr login -n myregistry -g myresourcegroup 39 ``` 40 41 NOTE: Once configured, Draft will inject a registry auth secret into the destination namespace deploying the chart to the cluster so the image can be pulled from the registry. 42 43 ## Drafting with DockerHub 44 45 To use [DockerHub](https://hub.docker.com) as your preferred registry, you must first have an account on DockerHub. 46 47 Once you have an account there, there are two steps for preparing Draft to use DockerHub as a target for pushing images. 48 49 1. Log in with `docker login` on the command line. 50 2. Set your preferred Draft registry. To do this, you need to know your DockerHub user name. 51 52 ```console 53 $ draft config set registry USERNAME 54 ``` 55 56 Unlike other registries, DockerHub does not need a registry URL. Just the user name will suffice. 57 58 Note that for DockerHub, Draft will not create a registry auth secret. 59 60 ## Running Tiller with RBAC enabled 61 62 To install Tiller in a cluster with RBAC enabled, a few additional steps are required to grant tiller access to deploy in namespaces. 63 64 [Helm's documentation](https://docs.helm.sh/using_helm/#role-based-access-control) on setting up Tiller in RBAC-enabled clusters is the best document on the subject, but for new users who just want to get started, let's create a new service account for tiller with the right roles to deploy to the `default` namespace. 65 66 ```shell 67 $ kubectl create serviceaccount tiller --namespace kube-system 68 serviceaccount "tiller" created 69 ``` 70 71 Let's define a role that allows tiller to manage all resources in the `default` namespace. In `role-tiller.yaml`: 72 73 ```yaml 74 kind: Role 75 apiVersion: rbac.authorization.k8s.io/v1 76 metadata: 77 name: tiller-manager 78 namespace: default 79 rules: 80 - apiGroups: ["", "extensions", "apps"] 81 resources: ["*"] 82 verbs: ["*"] 83 ``` 84 85 ```shell 86 $ kubectl create -f role-tiller.yaml 87 role "tiller-manager" created 88 ``` 89 90 Now let's bind the service account to that role. In `rolebinding-tiller.yaml`: 91 92 ```yaml 93 kind: RoleBinding 94 apiVersion: rbac.authorization.k8s.io/v1 95 metadata: 96 name: tiller-binding 97 namespace: default 98 subjects: 99 - kind: ServiceAccount 100 name: tiller 101 namespace: kube-system 102 roleRef: 103 kind: Role 104 name: tiller-manager 105 apiGroup: rbac.authorization.k8s.io 106 ``` 107 108 ```shell 109 $ kubectl create -f rolebinding-tiller.yaml 110 rolebinding "tiller-binding" created 111 ``` 112 113 We'll also need to grant tiller access to read configmaps in kube-system so it can store release information. In `role-tiller-kube-system.yaml`: 114 115 ```yaml 116 kind: Role 117 apiVersion: rbac.authorization.k8s.io/v1 118 metadata: 119 namespace: kube-system 120 name: tiller-manager 121 rules: 122 - apiGroups: ["", "extensions", "apps"] 123 resources: ["configmaps"] 124 verbs: ["*"] 125 ``` 126 127 ```shell 128 $ kubectl create -f role-tiller-kube-system.yaml 129 role "tiller-manager" created 130 ``` 131 132 And the respective role binding. In `rolebinding-tiller-kube-system.yaml`: 133 134 ```yaml 135 kind: RoleBinding 136 apiVersion: rbac.authorization.k8s.io/v1 137 metadata: 138 name: tiller-binding 139 namespace: kube-system 140 subjects: 141 - kind: ServiceAccount 142 name: tiller 143 namespace: kube-system 144 roleRef: 145 kind: Role 146 name: tiller-manager 147 apiGroup: rbac.authorization.k8s.io 148 ``` 149 150 ```shell 151 $ kubectl create -f rolebinding-tiller-kube-system.yaml 152 rolebinding "tiller-binding" created 153 ``` 154 155 Then, install tiller. 156 157 ```shell 158 $ helm init --service-account=tiller 159 ``` 160 161 ## Running Tiller in a namespace other than kube-system 162 163 To install Tiller in a namespace other than kube-system, a user can run `helm init` with the `--tiller-namespace` feature flag. This feature flag will deploy Tiller in that namespace. 164 165 There are a few prerequisites to make this work, however: 166 167 For minikube users, the setup documentation starts to look like this when deploying Tiller to the `draft` namespace: 168 169 ```shell 170 $ minikube start 171 $ kubectl create namespace draft 172 $ helm init --tiller-namespace draft 173 ``` 174 175 From then on, you can interact with Tiller either with the `--tiller-namespace` flag or by setting `$TILLER_NAMESPACE` in your client's environment. 176 177 ``` 178 $ draft up --tiller-namespace draft 179 $ export TILLER_NAMESPACE=draft 180 $ draft up 181 ```