# Architecture Design For CDE **URL:** \ **Category:** sdk-golang\ **Created:** [November 15, 2023, 5:28pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784 "2023-11-15T17:28:44Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![TheLumberjack](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/thelumberjack/32/113_2.png) [@TheLumberjack](https://openziti.discourse.group/u/TheLumberjack)\ **Post date:** [November 16, 2023, 1:29pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784/21 "2023-11-16T13:29:24Z")
So this would go something like: - define a new config type - create a new config of that type - use that type on your services ```auto ziti edge create config-type myconfig '{ "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "data": { "type": "array", "items": [{ "type": "object", "properties": { "port": { "type": "integer" }, "kind": { "type": "string" } }, "required": [ "port", "kind"] } ] } }, "required": ["data"]}' ziti edge create config myconfig.instance myconfig '{ "data": [{ "port": 1234, "kind": "java" }, { "port": 5678, "kind": "python" }, { "port": 9876, "kind": "javascript" }]}' ziti edge create service myconfig.service --configs "myconfig.instance" ``` Then, in your agent, it would ask for the config type "myconfig", read the json, and decide how to offload data. Without seeing the code it's hard to know for sure if that's what you're after, but that's the thing that comes to my mind ---
**Author:** ![sam-ulrich1](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/sam-ulrich1/32/1511_2.png) [@sam-ulrich1](https://openziti.discourse.group/u/sam-ulrich1)\ **Post date:** [November 16, 2023, 1:35pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784/22 "2023-11-16T13:35:34Z")
You get the idea pretty well the only difference is how the port forwarding works. So the main ports that are used are 13337 for code-server to expose the local editor to the end user and the vnc port (can't remember the number but it's another static port). Those are simple since we know at provision time which of those the end user will want. The hard part is the dymanic ports. Imagine you're working on a react app in the platform, you're going to want to run the app and view the local dev server to see the project as you build it. So the way it currently works is there is a tailscale connection to the agent from the server which basically exposes the entire local network of the pod to the main application server and then we perform application level auth to decide if we will expose the requested port to the user. So if you start your app you can open the local dev server @ https://-\.gigo.dev and when we get that request we can say from your cookies that you do own the workspace in question and permit the traffic to flow. ---
**Author:** ![sam-ulrich1](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/sam-ulrich1/32/1511_2.png) [@sam-ulrich1](https://openziti.discourse.group/u/sam-ulrich1)\ **Post date:** [November 16, 2023, 4:15pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784/23 "2023-11-16T16:15:04Z")
Are the configs parsed by the ziti system itself or is it a pass through to the edge nodes? Since it's a dynamic schema it seems like I can do whatever I want with the config ---
**Author:** ![sam-ulrich1](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/sam-ulrich1/32/1511_2.png) [@sam-ulrich1](https://openziti.discourse.group/u/sam-ulrich1)\ **Post date:** [November 16, 2023, 4:21pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784/24 "2023-11-16T16:21:20Z")
This seems to affirm my suspicion that the config is entirely dynamic > **[Service Configurations | OpenZiti](https://openziti.io/docs/learn/core-concepts/config-store/overview/)** > > Ziti Service Configurations, henceforth "Configs", may be associated with a service to provide metadata for the application that is being delivered by that service. ---
**Author:** ![TheLumberjack](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/thelumberjack/32/113_2.png) [@TheLumberjack](https://openziti.discourse.group/u/TheLumberjack)\ **Post date:** [November 16, 2023, 4:24pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784/25 "2023-11-16T16:24:29Z")
You make the config-type first, backed by a schema. Then you make an "instance" of that config type called just `config`. You then can associate that instance of a config to your service and your agent woudl be able to get that config when it 'binds' that service. Config types are parsed for validity, and configs are parsed for validity against the config-type (json schema) but that's the only 'parsing'. If that's what you mean? ---
**Author:** ![sam-ulrich1](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/sam-ulrich1/32/1511_2.png) [@sam-ulrich1](https://openziti.discourse.group/u/sam-ulrich1)\ **Post date:** [November 16, 2023, 5:29pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784/26 "2023-11-16T17:29:14Z")
I can expand on the reasons but as a simple question, how bad would it be to pass the config info in the name of the service instead of a config? All I need to share is a port and a net type: `gigo-agent--tcp:3000` ---
**Author:** ![TheLumberjack](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/thelumberjack/32/113_2.png) [@TheLumberjack](https://openziti.discourse.group/u/TheLumberjack)\ **Post date:** [November 16, 2023, 6:37pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784/27 "2023-11-16T18:37:59Z")
I mean. It seems reasonable to me. There might be a more idiomatic openziti way to do it but getting "something" working is always a great first step. I still haven't quite had time to digest/appreciate the problem yet. (I should get back to it later) But working code is working code. If that keeps you moving, go for it. Nothing comes to mind immediately as "oh no that's a bad idea". ---
**Author:** ![TheLumberjack](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/thelumberjack/32/113_2.png) [@TheLumberjack](https://openziti.discourse.group/u/TheLumberjack)\ **Post date:** [November 16, 2023, 9:23pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784/28 "2023-11-16T21:23:02Z")
> [@sam-ulrich1](#): > > So if you start your app you can open the local dev server @ https://-\.gigo.dev and when we get that request we can say from your cookies that you do own the workspace in question and permit the traffic to flow. Ok. I was able to give your post a bit of brainpower and let it sit to try to understand. When that request comes into `https://-.gigo.dev`, you want the user to land at their react app in that case? do I understand that properly? So you need to be able to dynamically send the port to the far side. Another thing came to mind for this. I think you want to use DialOptions... DialOptions are a blob of data that the dialing (your server) side can send to the terminating (binding) side. You could put json or serialize an int or whatever you want in there. When you dial, you use "DialWithOptions" and set the appata. On the far side when you accept a new connection, you read the appdata with `conn.GetAppData()`. It's on you to know if it's json, or protobuf or xml or whatever... 🙂 But that would allow your server to send a port dynamically. I think that'd solve the issue for you too. ---
**Author:** ![sam-ulrich1](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/sam-ulrich1/32/1511_2.png) [@sam-ulrich1](https://openziti.discourse.group/u/sam-ulrich1)\ **Post date:** [November 16, 2023, 9:34pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784/29 "2023-11-16T21:34:53Z")
Oh hell ya! That's so perfect ---
**Author:** ![sam-ulrich1](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/sam-ulrich1/32/1511_2.png) [@sam-ulrich1](https://openziti.discourse.group/u/sam-ulrich1)\ **Post date:** [November 16, 2023, 9:51pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784/30 "2023-11-16T21:51:24Z")
Are JWTs only available once? When I attempt to fetch the identity details a second time i doesn't return one ---
**Author:** ![TheLumberjack](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/thelumberjack/32/113_2.png) [@TheLumberjack](https://openziti.discourse.group/u/TheLumberjack)\ **Post date:** [November 16, 2023, 9:53pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784/31 "2023-11-16T21:53:03Z")
Yes. The JWT one gets from an identity are used for enrollment and are single use tokens. Once used the enrollment is removed. Identities are secrets and should be treated as such. ---
**Author:** ![sam-ulrich1](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/sam-ulrich1/32/1511_2.png) [@sam-ulrich1](https://openziti.discourse.group/u/sam-ulrich1)\ **Post date:** [November 16, 2023, 9:54pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784/32 "2023-11-16T21:54:55Z")
Okay thanks, good to know! ---
**Author:** ![sam-ulrich1](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/sam-ulrich1/32/1511_2.png) [@sam-ulrich1](https://openziti.discourse.group/u/sam-ulrich1)\ **Post date:** [November 16, 2023, 10:14pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784/33 "2023-11-16T22:14:58Z")
Here's my first pass at it. Agent will run on the pods agent instance and will receive the token through the bootstrap process. Once the agent comes online it will initialize and begin listening on the service. The Server will be used by server instances to dial Agents when we go to proxy requests. > > > //github.com/Gage-Technologies/gigo-lib/tree/67172f8e844b041660bcda7dc1b9e9c299a88370/zitimesh ---
**Author:** ![TheLumberjack](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/thelumberjack/32/113_2.png) [@TheLumberjack](https://openziti.discourse.group/u/TheLumberjack)\ **Post date:** [November 16, 2023, 10:16pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784/34 "2023-11-16T22:16:29Z")
nice! I'll give it a look 🙂 ---
**Author:** ![TheLumberjack](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/thelumberjack/32/113_2.png) [@TheLumberjack](https://openziti.discourse.group/u/TheLumberjack)\ **Post date:** [November 16, 2023, 10:22pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784/35 "2023-11-16T22:22:21Z")
Nice! As a side note, I see some tests too. If you need it, you can setup a super fast/easy local environment for testing things with `ziti edge quickstart`. That'll boot you up an ephemeral OpenZiti overlay network you can play with that's good for local testing. When the process exits it'll clean itself up. We haven't updated our doc to include that yet but it's gonna come soon i expect. ---
**Author:** ![sam-ulrich1](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/sam-ulrich1/32/1511_2.png) [@sam-ulrich1](https://openziti.discourse.group/u/sam-ulrich1)\ **Post date:** [November 16, 2023, 10:29pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784/36 "2023-11-16T22:29:28Z")
I just built the ziti docker compose into our dev compose. The project has a really dense external dependency set so we just ship a production like compose with the code and that way we can run real tests against things like ziti, nats, etcd, ... ---
**Author:** ![sam-ulrich1](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/sam-ulrich1/32/1511_2.png) [@sam-ulrich1](https://openziti.discourse.group/u/sam-ulrich1)\ **Post date:** [November 16, 2023, 11:05pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784/37 "2023-11-16T23:05:51Z")
Is there anyway to get the network stats of a service ---
**Author:** ![sam-ulrich1](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/sam-ulrich1/32/1511_2.png) [@sam-ulrich1](https://openziti.discourse.group/u/sam-ulrich1)\ **Post date:** [November 16, 2023, 11:08pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784/38 "2023-11-16T23:08:15Z")
We use the network monitoring to ensure we don't close a pod on someone whos working in a way that we can't see with other metrics ---
**Author:** ![TheLumberjack](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/thelumberjack/32/113_2.png) [@TheLumberjack](https://openziti.discourse.group/u/TheLumberjack)\ **Post date:** [November 16, 2023, 11:08pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784/39 "2023-11-16T23:08:59Z")
The controller emits metrics. You can ship them with a log shipper or use the prometheus scrape target. [Overview | OpenZiti](https://openziti.io/docs/learn/core-concepts/metrics/overview) The CloudZiti offering uses these along with a data lake to produce useful dashboards like this. I suspect that'll have what you need. (i think?) ![image](https://global.discourse-cdn.com/free1/uploads/netfoundry/original/2X/d/d52ec260769e494c2d986676099c777a2793995f.jpeg) ---
**Author:** ![sam-ulrich1](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/sam-ulrich1/32/1511_2.png) [@sam-ulrich1](https://openziti.discourse.group/u/sam-ulrich1)\ **Post date:** [November 16, 2023, 11:10pm UTC](https://openziti.discourse.group/t/architecture-design-for-cde/1784/40 "2023-11-16T23:10:00Z")
That looks like it will have everything I need! [Previous page](https://openziti.discourse.group/t/architecture-design-for-cde/1784.md?page=1) [Next page](https://openziti.discourse.group/t/architecture-design-for-cde/1784.md?page=3)