Mastering Local and Ephemeral Development with Kubernetes and Signadot

last week we explored ways to redirect traffic from maps running locally into those running in a cluster and vice versa during that discussion I completely ignored the fact that traffic mirroring is only a part of the story the second part is about deployments so today I thought to close the circle and try to find a tool that will do both I am looking not only for a way to mirror traffic from and to apps running locally but also to deploy new releases to infal environments like those generated as a result of creating pool requests in other words I'm looking for a tool that will do everything related to deployment and networking for all the phases of the development life cycle until the uper is deployed to [Music] production let's talk about development life cycle it starts on a laptop we are writing code of a new feature and while doing that we need to test that code that means two things we need to be able to run the app locally and we need to connect it to Baseline apps running somewhere else running the whole system locally is madness and I will not go into details of that part since we already covered that in this video once we are finished with a new feature we create a pull request I will leave out of this story the part that explains how someone might want to review the pull request how we should run unit tests how we should run linters security scans and so on and so forth all that should be done automatically through pipelines or what you might call CI what I want to focus on is the deployment part we want to be able to test both automatically and manually the new feature in the context of the whole system without tests we cannot know whether it behaves as expected and whether the pr should be merged to the mainline and ultimately deploy to production to test something especially in the context of the whole system we need to deploy it somewhere now just as it's Madness to deploy the whole system locally it is insane to deploy the whole system remotely as well while running the whole system locally poses problems with the resources your laptop might not be able to handle it we often do not have such restrictions in the cloud however deploying the whole system for each pool request would probably result in bankruptcy we could have tens or hundreds or even thousands of open PRS and multiplying the whole system for that number would be insane so what we want is to deploy only the bare minimum to test the new feature while relying on the Baseline system to provide all the dependencies and that poses two questions how do we deploy the bare minimum and how do we connect it to the Baseline system typically we would rely on different tools to answer those questions today however I want to explore a tool that might provide the answer to both of those questions the tool is called signal do and we are about to see it in action but before we do there is something important I have to say it might look like we are solving the same problem that telepresence mirror D and other tools are solving NVR however sarot tries to solve a few others so even if you say I already saw the solutions for this you will have to stay because we will solve some new ones a bit later with that out of the way let's get started there are quite a few different cases I want to cover today the first one is about local development how do we develop locally while being connected to remote apps for all the dependencies now already have a production like cluster up and running and all the applications are deployed to it those are two applications with Pinger depending on silly demo if you send a request to Pinger it will forward it to silly demo so testing one of those requires the other one to be running and we can confirm that by sending a request to Pinger and instructing it to Ping silly demo the output from Pinger is the message from silly demo next I will switch to a separate terminal go to the directory with Pinger source code and run the application and now comes the question what happens if I send a request to Pinger running locally to Ping silly demo it responded with I have no idea where Silly demo is silly demo is a backend application running in a production like cluster it is not accessible through Ingress and it would be silly to expose it just for me this is where signal do local comes into play now I can connect to the production like cluster and I can create the first send book by executing sign do send book Supply with the PA to the configuration file and a few variables which I will explain later send books environment is a kind of isolated environment containing only the bare minimum to test the new feature and connect it to the rest of the system for those of you like pretty colors uh we can see send boxes from a web UI as well now going back to the terminal I will repeat almost the same request as before the only thing I will modify is the address of silly demo signal do needs to know in which name space it is running so I edited next to the name of the service that's what I did this time my local up responded with a message from silly demo running in a remote cluster here's what happened I sent a request to Pinger running locally which in turn tried to communicate to the service C demo. demo on port 8080 signal do in turn intercepted that request and redirected it to the remote application behind that service to do that it changed my Etsy host file and added Network mappings to the cluster itself now if you paid attention I use a configuration file to help signal. figure out what I want so let's take a look at signal. Pinger local yaml in the nutshell I'm telling it which cluster to use through the variable instructing it to use a specific deployment in that cluster and map it to the application running locally on Port 880 now if I would be using e that's all I would need to do it would use it to configure virtual services to redirect traffic however I don't have is in this clust so I went for the alternative method to do that I had to add an annotation to deployment yam instructing sign do to inject a sidecar proxy for HTTP requests and that's all there is to it for the first use case so let me delete this uh sendbox by executing signal. sendbox delete with the same arguments as before let me switch from developing the pink up to Sly demo to do that I will stop Pinger from running locally and I will switch to the directory with s demo source code and I will run it next I will create a new Sandbox with almost the same command the only difference is that I'm using a different configuration file and this time the output is slightly different I got a special URL through which I can access Pinger running remotely let's see what I can do with that URL I'll store it in an environment VAR URL so that I do not have to remember it I'm old and I'll put the complete address I want to use now I can open Pinger running remotely in a browser we can see from the output that remote Pinger did not forward the request to remote Sly demo as it normally does instead the remote app forwarded the request to Sly demo running locally here's what happened I sent a request through the special signal. URL to Pinger running remotely Pinger in turn forwarded that request to cly demo however sigad do intercepted that request and redirected it to cly demo running locally let's take a look at the configuration file I used by outputting signal. S demo local yaml this one is similar to the first one except that this time I'm targeting Sly demo instead of Pinger there's also a new entry default route Group which tells sign do that I would like to generate a new end point based on Pinger running remotely so I'm developing silly demo locally and I'm exposing Pinger running remotely and now comes the interesting part what should we do once we're finished working locally and would like to test the new feature deployed remotely now before I we dive into that one which is probably the most interesting use case let me delete the sandbo by executing signal. sandbo delete and by the way I will also stop Sly demo from running locally we do not need local anything anymore we are now going towards creating pool requests imagine that you finished writing code and created a pool request which executed a pipeline that built a new image that we would like to test now I will not go into the details of creating CI pipelines that would be a subject of a different video what matters is that I'm faced with two problems when trying to test the new feature how do I redirect traffic from the application with the new feature to the rest of the applications running in the production like cluster and two how do I know what to deploy what is the minimum required to run that new feature let me start by resending the same request I sent to the at the very beginning of this video that was a request to Ping running in the production like cluster it forwarded the request to silly demo also running in the same production like cluster neither of those two apps contain the feature I want to test before merging the pier to the main line and moving it to production as you can guess I will create a new Sandbox the only difference besides using a different configuration file is that I'm using a variable tag to specify the image tag I want to use that's the image I built as result of the pipeline that executed when I created the pool request I got yet another special URL through which I can access Pinger however this time that will be Pinger in the sand box and not the one running in the production like cluster to be more precise sand bookes are at least in this context running in the same cluster so I really wanted to say that it is not the Baseline Binger let me store that URL in the environment variable now I can test or try it out with let's say curl right I'm not running real tests this time curl crl should be enough now there is an annoying part here I have to add signal API key header to the request so that sign do knows that I'm authorized to access the sandbox the rest is the URL itself the output is this time different it comes from Pinger in the sendbox which forwarded the request to Sly demo from the Baseline alternatively I can output the full address without the signal. API key and open it in a browser the result is the same and since it is coming from the browser there is no need for the API key since I'm already authenticated with signat we could have done the same from the UI if you open that specific send box we can see among other things the URL we can use to access it here's what happened the Baseline contained the Pinger which communicates with demo I created a copy of the necessary resources from the Pinger Baseline that saved me from having to deal with Pinger manifest choose what I need and what I don't how to reconfigure them to use dependent services from the Baseline and so on and so forth further on I sent a request to the Pinger in the sandbox which in turn forwarded it to Sly demo in the Baseline finally let's take a look at the configuration file I use by outputting signal. Binger yo there are quite a few few differences here to begin with i specify that I want to create a fork of the deployment called Pinger in the namespace configurable through the variable further on I specified customization by saying that the image should contain the tag specified through the variable finally the default route group is pretty much the same as before now let's take a look at what's running in that n space apart from the Baseline resources for Pinger and Sly demo there is a new deployment that's the fork created by sign do there is also a new service created automatically by sign do you should also notice that sigad do created sidecar containers in Baseline Pinger and silly demo pods those would not be needed if I use this the but since I don't have it signal do injected them to intercept traffic now let's imagine that we saw that something should be fixed we changed the code uh pushed it to the pull request and the pipeline executed again building New Image the to test those changes all we would have to do is execute the same command signal sbox apply but this time with a different tag variable now to be clear you should be executing commands like that through the same pipeline you're using to build image and do whatever else you're doing I'm running everything manually mostly to have a easier time showing what's happening anyways Let me refresh the browser and voila the new tag is running now there are quite a few uh both good and bad things about signal do that I want to discuss next but before I do let me delete the sandbox sign do is special some of the problems it tries to solve like Network mirroring are already solved by other tools like for example the presence what makes it special is that it combines solutions that already exist with some new ones specifically it enables us to Fork resources from the Baseline and modify them instead of trying to figure out what to deploy from scratch and how to isolate that from the rest of the system while still enabling communication between sand boxes and Baseline applications it comes with its own set of challenges though so let's start with cons to begin with signal do does not respect environment variable Cube config nor it has an argument to specify the path to the cube config file that's very annoying since it is often easier to have different Cube config files for different clusters instead of switching context and making the default Cube config a nightmare to manage next signal relies heavily on that c host uh file and that's great that's absolutely great what is not great is that it leaves the entries there even after the send box is deleted as a result your your Etsy host file will likely become a mess very very fast and you will have to clean it manually even though the entries scream at you with the comments do not delete me what else uh yeah signal dot is not open source I do not necessarily have a problem with that but its competition is open source so you would be hard pressed between choosing open source tools which lat you might upgrade to commercial versions or go with a commercial solution from the start now to be clear there is a free tier so you can still try it out also when I said that it is not open source I meant that the core is not open source signal do has a plugin system and plugins are open source what else uh there is no self-hosted version of signal do which might cause issue for those not being able or not wanting to use sus forking resources is limited to deployments Argo rollouts and a few plugins if you need to Fork other resources you will need to write the plugin yourself or wait until someone else does it for you I feel that forking of any resource should be a core feature and not something that should be done through plugins I think that sigad do could have made a more flexible config format and let users specify what to Fork aart to fields that should be changed and how to find services for networking speaking of signal configuration files I believe it would be better if they are backed by kubernetes crds and defined as CRS or custom resources instead of client side only configuration files if CRS were used it would work with let's say Argo CD and flux and it would integrate better with the rest of the ecosystem now there are CRS sign dos and boxes but those are created as a list instead of proper custom resources backed by a proper custom resource definition if those are usable if you could use those directly there is no documentation about it so I will say no you can't since sign do is forking or copying Baseline resources from the cluster it assumes that Baseline manifests do not change if for example we do modify the Baseline manifest as part of a new feature we are working on we would need to deploy them as Baseline resources and then Fork them that would defy the purpose of forking in a first place and finally um having to specify which resources to fork or to copy might be tedious wouldn't it be better if it would evaluate manifest of the new release and then apply only those that changed how about that now let's go to good things to Pros to begin with it solves the problem of sharing dependencies more or less effortlessly next it combines Network mirroring and deployment of new releases to pre-production environments into a single tool and that's awesome that's absolutely awesome finally documentation is absolutely great way too often relatively new projects have poor documentation making experience with them frustrating signal Do's documentation on the other hand is exceptionally good all in all I think that sign do is great but for specific use cases the idea of forking Baseline resources Works fairly well for monor repos and or distributed monoliths when it's fairly complicated to distinguish between what's part of the Baseline and what's part of the new feature on the other hand if you're developing microservices as independently Deployable small units it would make more sense if you just deploy in normal manifests in those cases sign do could have developed mutating admission controllers that would do the same thing it is doing now but without the need to specify what to fork in that case I would imagine the need for a few additional annotations just like the one I specified uh to let it know that it should create sidecar containers now I'm not saying that signal do is not a good solution as a matter of fact I like it I think it has a lot of potential I do not know of any other similar solution it solves a few problems some of them in a very unique way so go on try it out thank you for watching see you in the next one cheers

Channel: DevOps Toolkit

Views: 5,474

Keywords: DevOps, DevOps Toolkit, Kubernetes, Signadot, Viktor Farcic, developer environments, k8s, k8s dev env, kubernetes development environments, kubernetes environments, local development

Id: NZ8wEvVXKK8

Length: 20min 52sec (1252 seconds)

Published: Mon Sep 04 2023