Environment file

I would like to know more about this part in detail—the “some.other.name.com” is a DNS name, right? As for the IP, is overridden the public IP? Correct me if I’m wrong.

## Additional variables to override. 
#ZITI_EDGE_CONTROLLER_RAWNAME=some.other.name.com
#ZITI_EDGE_CTRL_ADVERTISED_HOST_PORT=some.other.name.com:1280
#ZITI_CTRL_ADVERTISED_ADDRESS=some.other.name.com
#ZITI_EDGE_CONTROLLER_HOSTNAME=some.other.name.com
#ZITI_CONTROLLER_HOSTNAME=some.other.name.com
#ZITI_EDGE_CONTROLLER_IP_OVERRIDE=20.20.20.20
DEFAULT_ENV_FILE

If I want to use the external DNS, I need to change it to the DNS name and override IP into public IP. But after some changes, I got into some errors when trying to zitiLogin.

RESTY 2023/01/03 00:54:21 ERROR Post "https://pssnet.ddns.net:1280/authenticate?method=password": x509: certificate is valid for ziti-controller, localhost, ziti, ziti-edge-controller, not pssnet.ddns.net, Attempt 5
error: unable to authenticate to https://pssnet.ddns.net:1280. Error: Post "https://pssnet.ddns.net:1280/authenticate?method=password": x509: certificate is valid for ziti-controller, localhost, ziti, ziti-edge-controller, not pssnet.ddns.net

This is just some testing or research things. So, from what I understand, before doing the quickstart installation, the PKI already signed everything except the DNS name, as I configured it after doing the installation docker-compose. I want to solidify my understanding of using the DNS name and configure it within the docker-compose. Is it even possible?

Yes, that means any fully qualified DNS name. I believe the "ADVERTISED" variables are the most important ones to pay attention to. In my opinion, the easiest thing to do is to keep them both the same, they are only separated to illustrate that the values can be different.

I expect what is happening here is that you changed the values after running the quickstart. The quickstart will create a full PKI for you when you run it but it needs these values set before you run it. If you change them after the fact, that's fine, you just have to regenerate the whole PKI. That is something most people don't want to deal with... In my opinion, if it's early into the overlay network's lifespan, it's really just easier to rerun the quickstart.

Since you are asking about doing this with docker-compose, I tried to mix all these things together to see if it would work properly. I wasn't successful for a myriad of reasons. I think it'll make the most sense for me and @gberl002 to take a look at this and see if we can come up with a process to make this work. I might just have done it wrong. We'll get back to you in a bit.

1 Like

Hi @himeose. After some trial and error today, I was able to get the sample docker-compose file corrected so that it would run properly but the edge router won’t function as is because the advertised hostname and port won’t be correct.

If you’re looking to run docker-compose and expose it to the internet, at this time we don’t have a good guide for that. I’ll get with @gberl002 again tomorrow and see what we can do.

2 Likes

It would be good if a solution to this can be identified… I would also like to use this demo setup

Hello @himeose

I use docker-compose for a test environment (OK Prod for home). I use the docker-simplified compose script, which just has the ZAC, Controller and Edge router. Reason for this, is that these are the components that I wanted without the extra stuff for testing.

This is available to the outside world (ie available over the Internet), and internally as well.

As for the ENV file, I am running this

ZITI_IMAGE=openziti/quickstart
ZITI_VERSION=latest
ZITI_CONTROLLER_RAWNAME=ziti-controller
ZITI_CONTROLLER_HOSTNAME=ziticontroller.example.com

ZITI_CTRL_ADVERTISED_ADDRESS=ziticontroller.example.com

ZITI_EDGE_CONTROLLER_RAWNAME=ziticontroller.example.com
ZITI_EDGE_CONTROLLER_HOSTNAME=ziticontroller.example.com
ZITI_EDGE_CTRL_ADVERTISED_HOST_PORT=ziticontroller.example.com:1280

This is an old setup, but still works. Points to note:
a) I only have one external IP (home network), so hence why everything is pointing to the same DNS name
b) I have de-fanged the above by replacing my hostname with example.com (so cliche’)

For the docker compose, I have all the ports bound to listening on the host address, ie this is my docker-compose script (note old references to ziti-blue and ziti-red) - use as a guide:

version: '2.4'
services:
  ziti-controller:
    image: "${ZITI_IMAGE}:${ZITI_VERSION}"
    env_file:
      - ./.env
    restart: always
    ports:
      - "1280:1280"
      - "6262:6262"
    networks:
      zitiblue:
        aliases:
          - ziti-edge-controller
      zitired:
        aliases:
          - ziti-edge-controller
    volumes:
      - prod-ziti-fs:/persistent
    entrypoint:
      - "/var/openziti/scripts/run-controller.sh"

  ziti-controller-init-container:
    image: "${ZITI_IMAGE}:${ZITI_VERSION}"
    depends_on:
      - ziti-controller
    environment:
      - ZITI_CONTROLLER_RAWNAME="${ZITI_CONTROLLER_RAWNAME}"
      - ZITI_EDGE_CONTROLLER_RAWNAME="${ZITI_EDGE_CONTROLLER_RAWNAME}"
    env_file:
      - ./.env
    networks:
      zitiblue:
        aliases:
          - ziti-edge-controller-init-container
      zitired:
        aliases:
          - ziti-edge-controller-init-container
    volumes:
      - prod-ziti-fs:/persistent
    entrypoint:
      - "/var/openziti/scripts/run-with-ziti-cli.sh"
    command:
      - "/var/openziti/scripts/access-control.sh"


  ziti-edge-router:
    image: "${ZITI_IMAGE}:${ZITI_VERSION}"
    environment:
      - ZITI_EDGE_ROUTER_RAWNAME=zitiedgerouter.thesmithcave.nz
    depends_on:
      - ziti-controller
    ports:
      - "3022:3022"
    restart: always
    networks:
      - zitiblue
      - zitired
    volumes:
       - prod-ziti-fs:/persistent
    entrypoint: /bin/bash
    command: "/var/openziti/scripts/run-router.sh edge"

  ziti-console:
    image: openziti/zac
    environment:
      - ZAC_SERVER_CERT_CHAIN=/openziti/pki/ziti-controller-intermediate/certs/ziti-controller-server.cert
      - ZAC_SERVER_KEY=/openziti/pki/ziti-controller-intermediate/keys/ziti-controller-server.key
    depends_on:
      - ziti-controller
    restart: always
    ports:
      - "1408:1408"
      - "18443:8443"
    volumes:
      - prod-ziti-fs:/persistent
      - type: bind
        source: /opt/container/prod/openziti/ziti-edge-controller-server.key
        target: /usr/src/app/server.key
      - type: bind
        source: /opt/container/prod/openziti/ziti-edge-controller-server.chain.pem
        target: /usr/src/app/server.chain.pem
    networks:
      - zitiblue
      - zitired

networks:
  zitired:
  zitiblue:

volumes:
  prod-ziti-fs:

Then, I have then forwarded the respective firewall ports (6262, 3022 and 1280) to the host running docker.

I echo @TheLumberjack, if you are early into setting this up, I would probably look to ‘start again’ with the PKI - using docker-compose down -v. This will blow away your volume, so you will be starting again from scratch, and re-setting up the PKI. Do this after you have the .env file configured to ensure all is configured the way you want to.listening.

Hope this is a good guide to get you started. Let me know if you have any issues.

2 Likes

I had a faint light-bulb going off around I think there might have been a github issue created to document and understand what all the different docker .env environment options are, ie difference between _RAWNAME and _HOSTNAME and are they one of the same. I did find the post that I was talking about: Bound to old controller / running ziti in production using docker - #11 by TheLumberjack. Maybe @gberl002 and @TheLumberjack can come to a consensus (if needed) across all environments around the naming convention and look to tidy up/document if needed?

1 Like

It’s good guidance, thank you for sharing, I forgot to change the ZITI_CONTROLLER_HOSTNAME before this. After config the yaml and env files, I restart it again. Now, I can access the controller flawlessly and add identity to the host. My environment for the controller and this setup is in the droplet. Meanwhile, the client using the zdew is on my main machine.

@gooseleggs thank you for providing feedback on this topic. I had not had this particular scenario before, so it definitely saved me some time. I did confirm I was able to use your setup, and it was successful.

Regarding the environment variables, this has been a pain point for a while, but it’s just one of those things that keeps slipping by. It is on our backlog to clean these up and make them more consistent across use cases, as well as just keep the naming convention consistent overall.

Thanks again for your input, it’s always great to see the community giving back. @himeose, please feel free to give any more feedback or ask any more questions you have.

1 Like