diff --git a/demos/hello-microshift-demo/README.md b/demos/hello-microshift-demo/README.md index 8334fc2..189fe93 100644 --- a/demos/hello-microshift-demo/README.md +++ b/demos/hello-microshift-demo/README.md @@ -52,11 +52,12 @@ Verify that the application is deployed and the route is accepted: NAME HOST ADMITTED SERVICE TLS hello-microshift hello-microshift.local True hello-microshift -Add an entry to `/etc/hosts` to map the application's route (`hello-microshift.local`) to the machine's primary IP: +Add an entry to `/etc/hosts` to map the application's route to the host's IP address. The route FQDN is in the `routes/hello-microshift` route object in the `demo` namespace. It will be `hello-microshift.local` but we'll use an oc command to output the route into a BASH variable named `route`. We then associate the host's IP to the route FQDN to the /etc/hosts file. hostIP=$(ip route get 1.1.1.1 | grep -oP 'src \K\S+') - sudo sed -i .bak '/hello-microshift.local/d' /etc/hosts - echo "${hostIP} hello-microshift.local" | sudo tee -a /etc/hosts + route=$(oc get routes/hello-microshift -n demo -o=jsonpath={.spec.host}) + sudo sed -i.bak '/hello-microshift.local/d' /etc/hosts + echo "${hostIP} ${route}" | sudo tee -a /etc/hosts Now, trying to `curl` the application's route should return the "Hello, MicroShift!" HTML page: @@ -71,7 +72,15 @@ Next, let's access the cluster and application from outside the MicroShift machi If you're running the MicroShift on a VM _and_ your hypervisor connects instances via NAT, make sure to create port mappings from the hypervisor to guest ports 22 (ssh), 80 (http), and 6443 (K8s API). -Once more, you need to edit `/etc/hosts` to resolve `hello-microshift.local` to the MicroShift machine's IP, then you can `curl` the route and also access the page in your browser: +On the MicroShift machine, ensure proper `firewalld` services are open. Use the following command on the MicroShift machine to open the services in the running config of `firewalld`. + + sudo firewall-cmd --add-service={ssh,http,kube-apiserver} + +If you reboot the MicroShift machine, then these rules will be lost. To make the `firewalld` rules permanent, you may type on the MicroShift machine: + + sudo firewall-cmd --runtime-to-permanent + +On your host that is attempting to access the MicroShift machine, you must to edit `/etc/hosts` to resolve `hello-microshift.local` to the MicroShift machine's IP, then you can `curl` the route and also access the page in your browser: [user@core ~]$ curl http://hello-microshift.local @@ -80,13 +89,13 @@ Once more, you need to edit `/etc/hosts` to resolve `hello-microshift.local` to To remotely access the cluster using the `oc` client, copy the kubeconfig from the MicroShift machine to your local machine. Then update the URL of the `server:` field in the kubeconfig to point to your MicroShift machine: - mkdir -p ~/.kube/config - ssh -o "IdentitiesOnly=yes" -i ./builds/hello-microshift/demo/id_demo microshift@$MACHINE_IP "sudo cat /var/lib/microshift/resources/kubeadmin/kubeconfig" > ~/.kube/config - sed -i .bak 's|server: https://127.0.0.1:6443|server: https://hello-microshift.local:6443|' ~/.kube/config + mkdir -p ~/.kube + ssh -o "IdentitiesOnly=yes" -i ./builds/hello-microshift-demo/id_demo microshift@$MACHINE_IP "sudo cat /var/lib/microshift/resources/kubeadmin/kubeconfig" > ~/.kube/config + sed -i.bak 's|server: https://127.0.0.1:6443|server: https://hello-microshift.local:6443|' ~/.kube/config -Now you can access the cluster remotely: +Now you can access the cluster remotely. However, the `--insecure-skip-tls-verify=true` parameter must be set because the x509 on the MicroShift demo machine is not valid for `hello-microshift.local`. In production, an administrator would generate a proper x509 with a chain of trust, but this is just a demo. - [user@core ~]$ oc get pods -n demo + [user@core ~]$ oc --insecure-skip-tls-verify=true get pods -n demo NAME READY STATUS RESTARTS AGE hello-microshift-6bdbc6c444-8sjc6 1/1 Running 0 45m hello-microshift-6bdbc6c444-bm5j4 1/1 Running 0 45m