3 posts tagged with "local"

In our last post we showed how an AI skill can generate a complete interactive workshop for the Educates training platform. The result was a working workshop for the Air Python web framework, and you can browse the source in the GitHub repository. But having workshop source files sitting in a repository is only half the story. The question that naturally follows is: how do you actually deploy it?

If you've used platforms like Killercoda, Instruqt, or Strigo, the answer would be straightforward. You push your content to the platform, and it handles the rest. But that convenience comes with a trade-off that's easy to overlook until it bites you.

When running Educates locally on macOS, your cluster's accessibility depends on your machine's IP address. Every time you move between networks — home, office, conference WiFi — your IP changes. DNS resolution breaks, cluster ingresses stop responding, and workshop URLs go stale. This can be a hassle — especially when you don't immediately realize the IP changed and spend time debugging something else entirely. You end up manually updating the resolver configuration before you can get back to work.

In the How to best work locally post, we showed how to configure a local DNS resolver with a recognizable domain like educates.test. And in Automating DNS Resolver Updates, we covered how to detect IP changes and re-sync the resolver automatically. Both of those approaches react to the IP change after it happens. The approach in this post eliminates the change altogether. A better approach is to prevent the problem entirely: give your machine a fixed IP that never changes, regardless of which physical network you're on.

When you run Educates locally, it's easy to go with the defaults, just create your Educates cluster as explained in the Getting Started on Kind article.

But that is not the most optimal workflow. Why?

Because we recommend using SSL for your local environment, and for that, we also recommend to use a recognizable DNS name for your cluster. This makes things easier, and also shields you from roaming, so that when you move from one location to another, and your ip changes, the nip.io address change don't affect you. Also, using a name for your cluster makes things easier when you want to have your descriptors or config under version control.

We will demonstrate how to:

• Create a local Certificate Authority (CA) so that you can have trust between your local computer and your cluster
• Configure a local DNS resolver to provide your cluster with a recognizable name
• Create your cluster so that it uses both and creates ingresses to your workshops using working SSL