This Ziti TV will be another working session and office hours. Docker is a convenient mechanism for deploying applications, but it's easy to get lost along the way. We'll take a look at the existing docker quickstarts, how they work and how to troubleshoot them.
If you have any questions, we'll take those too, fire away! You can ask here or live.
Hello
I have followed all the videos you recommended, but it seems that there are some errors when creating the configurations 'Web-hello-world-host-config' and 'Web-hello-world-intercept-config.' Could you help me verify?
Thank you very much, I may have misunderstood it. Initially, I followed everything completely, but it seems that my client machine cannot connect to openziti/hello-world. Is it possible for you to help me verify?.Do I need to map the host or change the IP/DNS settings?
❯ ping ziti.tv.docker.example
PING ziti.tv.docker.example (100.64.0.3): 56 data bytes
64 bytes from 100.64.0.3: icmp_seq=0 ttl=255 time=1.319 ms
64 bytes from 100.64.0.3: icmp_seq=1 ttl=255 time=0.565 ms
64 bytes from 100.64.0.3: icmp_seq=2 ttl=255 time=0.593 ms
64 bytes from 100.64.0.3: icmp_seq=3 ttl=255 time=0.330 ms
64 bytes from 100.64.0.3: icmp_seq=4 ttl=255 time=0.651 ms
64 bytes from 100.64.0.3: icmp_seq=5 ttl=255 time=0.364 ms
^C
--- ziti.tv.docker.example ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.330/0.637/1.319/0.327 ms
~ 5s
❯ curl http://ziti.tv.docker.example:9000
You need to be careful with ping. Ping it a classic IP based tool. Though it appears to work with ziti in this case, ziti doesn't tunnel icmp at this time. If your curl command fails, you need to look in your tunneler logs for the reason why. Look through those logs and it should become clear, or there will be log messages that might map to another forum post with more help.
I would expect you to see a log message indicating something like, "NO_EDGE_ROUTER" in the client logs. The other way would be to open the routers config file, find the advertised address for the edge listener, and use openssl s_client to connect to the edge router. That will verify the router is online and reachable.
After the client connects, I checked the logs on the Controller and found the following logs. Where should I start troubleshooting?
this is logs
"ziti-controller-1 | [ 47.352] ERROR transport/v2/tls.(*sharedListener).processConn [tls:0.0.0.0:7501]: {remote=[202.129.207.11:61343] error=[remote error: tls: unknown certificate authority]} handshake failed
ziti-controller-1 | [ 52.375] ERROR transport/v2/tls.(*sharedListener).processConn [tls:0.0.0.0:7501]: {error=[remote error: tls: unknown certificate authority] remote=[202.129.207.11:61412]} handshake failed"
My guess is that these errors are generally from using the ziti CLI tool with username/password auth and not certificate auth. Here on top I've started a controller and on bottom i login to it. You'll see every time i login, i get that error. All it's telling you is that a connection is being established without verifying the incoming certificate first.
Are you having some other issue, or are you just looking through logs and wondering if this is some error to be concerned with?
Hi Clint. I wanted to duplicate this with Oracle cloud services as opposed to aws. I am having a problem with the advertised addresses variables in the .env file. For example, in aws you set ZITI_CTRL_EDGE_ADVERTISIED_ADDRESS= ,. For Oracle I set it to my public IP address. When I do the and run docker compose up I get the following error: "dependency failed to start: container -ziti-controller-1 is unhealithy". ANy idea what causes this? Thanks for your help !
Hi @DavidH - welcome to the community and to OpenZiti!
So I tried this myself a couple of times and things worked as expected and I went to record a video to illustrate it working and low and behold -- i ALSO got a "dependency failed to start: container -ziti-controller-1 is unhealithy"!
I think it's due to the healthcheck. When I looked back at the video it took my controller 35 seconds to start and the healthcheck is marked to retry 30 times by default... I changed it over to retries: 60 and it's started up 3 out of 3 tries.
If needed, here's what my final .env file looked like (change the ZITI_PWD obv ):
# OpenZiti Variables
ZITI_IMAGE=openziti/quickstart
ZITI_VERSION=latest
# the user and password to use
# Leave password blank to have a unique value generated or set the password explicitly
ZITI_USER=admin
ZITI_PWD=
ZITI_INTERFACE=0.0.0.0
# controller name, address/port information
ZITI_CTRL_NAME=ziti-controller
ZITI_CTRL_EDGE_ADVERTISED_ADDRESS=3.142.245.63
ZITI_CTRL_ADVERTISED_ADDRESS=3.142.245.63
ZITI_CTRL_EDGE_IP_OVERRIDE=3.142.245.63
ZITI_CTRL_EDGE_ADVERTISED_PORT=7640
ZITI_CTRL_ADVERTISED_PORT=7641
# 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-edge-router
ZITI_ROUTER_ADVERTISED_ADDRESS=3.142.245.63
ZITI_ROUTER_PORT=7644
ZITI_ROUTER_IP_OVERRIDE=3.142.245.63
ZITI_ROUTER_LISTENER_BIND_PORT=7643
#ZITI_ROUTER_ROLES=public
Thank you! That seems to be the issue. I managed to get docker compose to work on my Oracle instance and was able to fire up ZAC. I did get a couple of error messages, however:
BTW I had to restart the instance and I wanted to set the enrollment duration to something longer than 7 days, so I just stuck in 1 year and I got an error. I changed it to 70 days instead of 7 and it worked fine.
Excuse me. I have followed the steps to deploy the edge router container without any issues. I also created another edge router container for redundancy named 'Ziti-Router-edge-test.' However, it seems that packets are sent to Ziti-Router-edge first before being forwarded to Ziti-Router-edge-test. If Ziti-Router-edge goes down, clients cannot access the backend services. Is it possible to configure Ziti-Router-edge and Ziti-Router-edge-test to work in active-active mode?.
This is a diagram
nc-user@docker-ziti:~/version1$ cat .env
# OpenZiti Variables
ZITI_IMAGE=openziti/quickstart
ZITI_VERSION=latest
# the user and password to use
# Leave password blank to have a unique value generated or set the password explicitly
ZITI_USER=admin
ZITI_PWD=
ZITI_INTERFACE=0.0.0.0
# controller name, address/port information
ZITI_CTRL_NAME=ziti-controller
ZITI_CTRL_EDGE_ADVERTISED_ADDRESS=ziti-edge-controller
ZITI_CTRL_ADVERTISED_ADDRESS=ziti-controller
#ZITI_CTRL_EDGE_IP_OVERRIDE=10.10.10.10
#ZITI_CTRL_EDGE_ADVERTISED_PORT=7501
#ZITI_CTRL_ADVERTISED_PORT=7502
#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-edge-router
#ZITI_ROUTER_ADVERTISED_ADDRESS=ziti-edge-router
#ZITI_ROUTER_PORT=7601
#ZITI_ROUTER_IP_OVERRIDE=10.10.10.10
#ZITI_CTRL_ADVERTISED_PORT=1280
#ZITI_ROUTER_LISTENER_BIND_PORT=7602
#ZITI_ROUTER_ROLES=public
Hi @Samitthichots. I'm not clear on whether both Ziti-Router-edge and Ziti-Router-edge-test are exposed to clients? If they are, then ziti will already take care of that active-active type of request. If one router goes down, traffic should go to the other router as long as both are configured as edge routers and as long as client can connect to both routers.
If Ziti-Router-edge-test is the router offloading packets, and Ziti-Router-edge is the only edge router available, what you describe would make sense. If that's how it's setup, you can add a separate router or you can do as I've tried to explain above. Hope that helps.