Hi all… I am about to turn loose this service for a production instance. I am making the assumption that the first router hostname can be the same as the controller name, since they resolve to the same place. Is that OK? Or do I need to do something separate?
Also, is there a great significance to the chosen port#s versus the default ones? It nice that they are in numerical order.
Also, the initial password isn’t an issue if I change it immediately, right? It never tries to apply that password on subsequent compose up actions, correct?
# controller name, address/port information
ZITI_CTRL_NAME=ziti.mydomain.com
ZITI_CTRL_EDGE_ADVERTISED_ADDRESS=ziti.mydomain.com
ZITI_CTRL_ADVERTISED_ADDRESS=ziti.mydomain.com
ZITI_CTRL_EDGE_IP_OVERRIDE=10.10.10.10
ZITI_CTRL_EDGE_ADVERTISED_PORT=8441
ZITI_CTRL_ADVERTISED_PORT=8440
# The duration of the enrollment period (in minutes), default if not set. shown - 7days
ZITI_EDGE_IDENTITY_ENROLLMENT_DURATION=10080
ZITI_ROUTER_ENROLLMENT_DURATION=10080
# router address/port information
ZITI_ROUTER_NAME=ziti.mydomain.com
ZITI_ROUTER_ADVERTISED_HOST=ziti.mydomain.com
ZITI_ROUTER_PORT=8442
ZITI_ROUTER_IP_OVERRIDE=10.10.10.10
ZITI_ROUTER_LISTENER_BIND_PORT=8444
ZITI_ROUTER_ROLES=public
Yep. That would be what I would expect. If you want to verify, when the config is generated, the 'advertise' address in the generated configs needs to be correct along with the CSR section of the router config. Whatever ends up in the 'advertise' just needs to also be in the dns section, which the quickstart should do (unless there's a bug).
None whatsoever. In fact, in the upcoming releases we'll be changing these ports so that they can all be one single port! That doc isn't ready yet, but should be "soon". The biggest reason to use something over 1024 is so that you can run the process without being root but for CloudZiti, we often will use port 443 and port 80 because those ports tend to be more "outbound firewall friendly". Some companies will block the non-standard ports (anything not 443 and 80 basically).
Correct. BUT if you change it, just realize that the helper function/alias of zitiLogin won't work. That's hopefully obvious, but it catches a lot of people off guard if they're not aware of how shell variables work etc.
So as long as you're using ziti edge login "${ZITI_CTRL_EDGE_ADVERTISED_ADDRESS}:${ZITI_CTRL_EDGE_ADVERTISED_PORT}" -u "${ZITI_USER-}" -p "${ZITI_PWD}" -y then you're good to go...
I have some aliases on my system, so I should be good there. But is it common to have the password in plaintext on that system? I plan on restricting access to the ZAC 8443 to my host, but the other ports will be exposed. Other than routine docker compose pull && docker compose up -d, and apt upgrade, I don't think there are other patches I need to do (which is why I like containers).
"common"? I mean, if it were me and my system, I'd probably eventually remove that file entirely after I have my feet under me. Also, the quickstarts have never been positioned as a "this is how you get to production" but instead are more of a "let's get you up and running for you to try things out and you can harden it later". For example, by removing this particular file after you're pleased with your understanding of OpenZiti. We have a whole plan to provide a "from quickstart to production" type of punchlist of things to do in order to bring your deployment to a production level but it's a big task trying to outline all those sorts of things and it's still not a priority for us to write. We'll get there, but we haven't gotten there yet.
Then there's the standard trope of using proper file system privileges and not allowing access to content someone shouldn't have access to etc.
As long as you're happy not needing it, by all means feel free to remove the whole file!
Yeah, that's kind of what I was thinking. I tinkered with working with just the containers, but gave up shortly after seeing the entrypoint is a script and putting it on the pile for later.
Another evolution of the docker quickstarts will be a guide illustrating how to go from quickstarts to the slim and trim, no frills containers like those used by the kubernetes stuff. Our friend @qrkourier works a lot around kubernetes and we also deploy bare-bones type containers too but they don’t do anything for you and we don’t have a lot (any?) doc for them outside of kubernetes yet. Well, I don’t think we do.
If you wanted to put something on the pile, that might be something you’d want to look at. Another one of those things we’ll get around to doing at some point, just not there yet.
