Tectonic Services are the applications that are installed into your cluster. These include:
|Tectonic Console||Web management console for Kubernetes and the services themselves|
|Tectonic Identity||Centralized user management for services on your cluster|
|Tectonic Support||Service for the Tectonic Support team to help understand what is happening in your cluster|
|Quay Enterprise||The award-winning Docker Registry, based on Quay.io|
|CoreUpdate||Manage upgrades of your CoreOS hosts and your applications|
All Tectonic Services run on Kubernetes and are installed with
kubectl. We'll use it to install all of the included services, then configure your Tectonic license, and finally configure the Tectonic Console so your users can access it.
If you didn't configure
kubectl during cluster installation, follow this guide.
Before installing services, make sure you created the
from the second step of the deployer guide.
Download the Tectonic Services template and submit it to the cluster:
$ kubectl create -f tectonic-services.yml replicationcontrollers/tectonic-manager
The Tectonic Services are run within a separate namespace,
tectonic-system, in order to group them together and keep them out of your way. You're encouraged to use namespaces for your company's teams, projects or deployment environments.
Next, we need to install your license in order to complete the installation of the Tectonic Services. You can find your license in your Tectonic account.
The license is stored within the cluster as a Secret, which is a secure way to expose sensitive data to applications in Kubernetes. Your Tectonic License should be pre-formatted as a Secret and should look similar to:
apiVersion: v1 kind: Secret metadata: name: tectonic-license namespace: tectonic-system type: Opaque data: license: 5SiztAC4BPJo28fhFUy6hjYSQBbyW7Sn2sQg4P7xPA...
Once you've obtained your license, place it in a file called
tectonic-license.yml (template) on your local machine.
Now all we need to do is submit the Secret into the cluster:
$ kubectl create -f tectonic-license.yml secrets/tectonic-license
Kubernetes supports a special type of secret, called a Pull Secret, that is used for pulling containers from a private Docker registry. Tectonic uses this to pull down the containers that run the Tectonic Services.
You can find a pre-generated Pull Secret in your Tectonic account. It should looks similar to:
apiVersion: v1 kind: Secret metadata: name: tectonic-pull-secret namespace: tectonic-system type: kubernetes.io/dockercfg data: .dockercfg: OVXRFVkVSUyIsCiAgImVtYWlsIjogIiIKIH0KfQ...
Once you've obtained your pull secret, place it in a file called
tectonic-pull-secret.yml (template) on your local machine.
Now, like before we submit the Secret into the cluster:
$ kubectl create -f tectonic-pull-secret.yml secrets/tectonic-pull-secret
With the license and pull secret in place, the Tectonic Services will be downloaded and configured. This process can take a few minutes to complete.
You can check the if the Tectonic Services were correctly deployed by running:
$ kubectl --namespace=tectonic-system get pods NAME READY STATUS RESTARTS AGE tectonic-console-y84qu 1/1 Running 0 5s tectonic-manager-a7d9a 1/1 Running 0 7s tectonic-support-nbyxs 1/1 Running 0 4s
Once the pods reach
Running status, everything should be configured properly.
By default, the Tectonic Services are not exposed outside the cluster. For example, we observed the pod running the Tectonic Console, but we don't have a convenient way to access it. To do this, we can create a Kubernetes Service that exposes the Console, as well as the Identity service it depends on. This step requires careful consideration because it exposes the services directly to the open network.
There are two main ways of configuring a service to expose it outside of the cluster, the NodePort and the LoadBalancer.
A feature of a Kubernetes service is a NodePort, which is a mechanism to expose the service on a specific port on every machine in the cluster. You would then browse to the specific port on any machine to load the Console. In addition, using a NodePort will allow any machine in the cluster to function as a backend for a load balancer.
This service definition (template) will expose the Tectonic Console on port 32000, using NodePort:
apiVersion: v1 kind: Service metadata: name: tectonic-console-public namespace: tectonic-system spec: type: NodePort ports: - port: 80 nodePort: 32000 protocol: TCP name: tectonic-console-expose selector: tectonic-app: console tectonic-component: ui
The next definition exposes the Identity Worker on NodePort 30556:
apiVersion: v1 kind: Service metadata: name: tectonic-identity namespace: tectonic-system labels: tectonic-app: identity spec: selector: tectonic-app: identity tectonic-component: worker type: NodePort ports: - protocol: TCP port: 5556 nodePort: 30556
Now, create the service. You'll see a warning about exposing the service to the network:
$ kubectl --namespace=tectonic-system create -f https://tectonic.com/docs/latest/deployer/files/tectonic-console-public.yml You have exposed your service on an external port on all nodes in your cluster. If you want to expose this service to the external internet, you may need to set up firewall rules for the service port(s) (tcp:32000) to serve traffic. See http://releases.k8s.io/HEAD/docs/user-guide/services-firewalls.md for more details. services/tectonic-console-public
Now you should be able to navigate to
https://<host>:32000 where "host" is any node in the cluster.
If you are using a Kubernetes deployment on Google or AWS and have configured your cloud credentials as a Secret, using the service type "LoadBalancer" will create a new cloud load balancer and expose the service through it. Example (template):
apiVersion: v1 kind: Service metadata: name: tectonic-console-cloud namespace: tectonic-system spec: type: LoadBalancer ports: - port: 80 protocol: TCP name: tectonic-console-expose selector: tectonic-app: console tectonic-component: ui
$ kubectl --namespace=tectonic-system create -f https://tectonic.com/docs/latest/deployer/files/tectonic-console-cloud.yml services/tectonic-console-cloud
If you haven't configured your cloud credentials, the service will still be created, but the cloud load balancer won't be created.