Hello there!
Are there any good articles on how to build ziti network from scratch?
I mean without using docker(-compose), or a helper sh script that comes as ziti-cli-functions.
Like by getting hands on of ziti CLI and doing everything manually. PKI intializing, networking, etc.
Thanks.
No. It's a common desire but it's not there yet. There's a discourse post from the past where someone asked you should check out. I narrated a video that's linked on that discourse:
I also basically plan to do the same thing this week for Ziti TV so you could tune in for that at 11 am ET. I'll field questions too if you want 
Other than that you can just "read the bash". The quickstart script itself is relatively approachable bash. The function you'll want to start with is expressInstall https://get.openziti.io/ziti-cli-functions.sh (or on github here )
As I said, I plan to go through all these steps Friday on Ziti TV. For now, those are the best resources I have to share.
The from-scratch.sh script is pretty neat.
The only thing that I miss is specifically separating the node where controller runs and the node where edge router runs. So that it's more verbose in terms of communications between those nodes and components.
Also would be neat to have security best practices recommendations in terms of hardening the controller itself. Like exposing to the Internet only the ports that are used by routers in order to lower the footrpint for the potential attack, apparmor profiles, seccomp, etc.
Thank you for replying with the nearest possible solution and finding the time to mention the upcoming stream!
Ok. more reading and video watching.
In July of 2022 Ken and I did this Ziti TV
It shows you how to successfully 'harden' the ziti controller by "splitting" the management API off and away from the public internet.
This topic was also covered in discourse in 2022 here: Making ZAC dark - #6 by TheLumberjack and lightly here OpenZiti configuration files - #5 by TheLumberjack and ZAC On different host than the controller - #2 by TheLumberjack
As for separating the node from the controller/router, I might caution not to do that but -- that's also been covered in a recent post here Building simple network from scratch - Help - #13 by TheLumberjack where I demonstrate how to have three totally separate machines interconnect but you can also find other posts of that flavor on discourse too I think. Also, the "docker - no compose" quicsktart very specifically shows you how to accomplish that pretty clearly too imo. Local - With Docker | OpenZiti
One part that's missing (on our 'todo' list) is to update the quickstarts to use ALPN. Right now, you'll see all our quickstart / doc refer to the "control plane port" (where routers communicate to the controller) and the "client api/management api" port (where the REST-based api is). Well now-a-days you can just use the same port and with ALPN ziti will figure out if you meant http traffic or control plane traffic... Same for routers too. Routers need two ports in our quickstarts one for router to router comms (the data plane) and one for edge clients to connect (tunnelers/sdks/etc)... ALPN solves that too.... So that's "out there" but not in our quickstarts yet.
hope that helps...
Any infornation on why not to separate controller from the edge controller?
Do you think this schema will work?
I knew I should have just expanded on that part of my original reply ... 
so the schema you have shown WILL definitely work, yes! The challenge you'll face is that accessing the management API will only be possible from the Cloud Provider C -> VPC -> VM! That's exactly why I would keep that router in the controller actually.
When you split off the API you'll no longer be able to access it so your ziti CLI commands, or your ZAC if you install it, will only work if they are local to that VM.
Now, if you had an edge router on that VM, you could use it to offload a service to 127.0.0.1:20000 (or whatever port you picked)!! That's why I was cautioning you from removing it, because it would be very useful to be able to administer the overlay --- via the overlay. Relying on local ziti commands only as a last resort if the overlay is somehow unresponsive.
I figured this question was coming, but you got there much faster than i expected!!! 
So that's why. Other than that - there's no reason why your schema won't work perfectly fine.
I see now why. Thanks for the clarification!
Basically a VM with a controller becomes it's own local silo with a local ziti cli to administer the network.
edited:
updated the schema above with comments
I wonder, would this problem be remediated if I just deploy private router next to the controller?
edited:
something like this?
edited2:
updated diagram
You got it! That's a very reasonable thing to do indeed!
