# Tunneler Container Update

**URL:** <https://openziti.discourse.group/t/tunneler-container-update/959>\
**Category:** Ziti Edge Tunnel\
**Created:** [January 5, 2023, 3:55pm UTC](https://openziti.discourse.group/t/tunneler-container-update/959 "2023-01-05T15:55:16Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![qrkourier](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/qrkourier/32/52_2.png) [@qrkourier](https://openziti.discourse.group/u/qrkourier)\
**Post date:** [January 5, 2023, 3:55pm UTC](https://openziti.discourse.group/t/tunneler-container-update/959/1 "2023-01-05T15:55:16Z")

</div>

You may have noticed that there are now two tunneler containers ([README](https://github.com/openziti/ziti-tunnel-sdk-c/tree/main/docker#readme)). Both are released automatically along with the `ziti-edge-tunnel` executable [release in GitHub](https://github.com/qrkourier/ziti-tunnel-sdk-c/releases).

### What's the difference between the two containers?

The original container is `openziti/ziti-edge-tunnel` and helps with deployment by providing several ways to supply the Ziti identity. This container assumes you want the "run" mode of the tunneler, which provides a proxy and nameserver. We'll keep releasing this container for stability and compatibility for the time being, but the new container is better suited in most cases. I wouldn't say the new container deprecates the old.

The new container is `openziti/ziti-host` and uses the same methods of configuring the Ziti identity and uses the "run-host" mode of the tunneler (service hosting only without a proxy or nameserver). The main reason I started creating another container was to prepare for Red Hat certification. This resulted in a ~~thinner~~ container image focused on the service hosting/terminating use case. This container also complies with container best practices, such as dropping privileges to improve security (no root).

EDIT: struck ~~thinner~~ because the RH base image is in fact approx 2x the size of the Debian image

---

<div class="post-metadata">

**Author:** ![gooseleggs](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/gooseleggs/32/450_2.png) [@gooseleggs](https://openziti.discourse.group/u/gooseleggs)\
**Post date:** [January 5, 2023, 6:43pm UTC](https://openziti.discourse.group/t/tunneler-container-update/959/2 "2023-01-05T18:43:03Z")

</div>

I have done a cursory glance at this. From looking at the readme, there is no indication that there are two container images until you read all the way through, and then you come up to another _Container Image ..._ headline (thinking of someone coming along in a few months time).

Could I ask that you summarize what you have written above into that readme? Basically explain at the top that there are two containers now - which one should be chosen and why the differences?

Also, on the Docker-compose file [https://github.com/openziti/ziti-tunnel-sdk-c/blob/main/docker/docker-compose.yml](https://github.com/openziti/ziti-tunnel-sdk-c/blob/main/docker/docker-compose.yml) there are a lot of services in there, and when you run

> 1. Run the demo server
> 
> docker-compose up --detach hello

Is this not bringing up everything (all the services) including the older `ziti-edge-tunneler`?

I feel it is a shame that you are going away from the `ziti-edge-tunneller` name as that is universal, ie run the ziti-edge-tunneller app on all platforms, except for docker where it is now called `ziti-host`. Will this bring confusion into the mix? I understand that you cannot have two different containers with the same name.

---

<div class="post-metadata">

**Author:** ![qrkourier](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/qrkourier/32/52_2.png) [@qrkourier](https://openziti.discourse.group/u/qrkourier)\
**Post date:** [January 6, 2023, 4:10pm UTC](https://openziti.discourse.group/t/tunneler-container-update/959/3 "2023-01-06T16:10:07Z")

</div>

> [@gooseleggs](#):
>
> Could I ask that you summarize what you have written above into that readme? Basically explain at the top that there are two containers now - which one should be chosen and why the differences?

Great idea! [describe the differences between the two containers by qrkourier · Pull Request #580 · openziti/ziti-tunnel-sdk-c · GitHub](https://github.com/openziti/ziti-tunnel-sdk-c/pull/580)

---

<div class="post-metadata">

**Author:** ![qrkourier](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/qrkourier/32/52_2.png) [@qrkourier](https://openziti.discourse.group/u/qrkourier)\
**Post date:** [January 6, 2023, 4:14pm UTC](https://openziti.discourse.group/t/tunneler-container-update/959/4 "2023-01-06T16:14:49Z")

</div>

> [@gooseleggs](#):
>
> Is this not bringing up everything (all the services) including the older `ziti-edge-tunneler`?

No, that command only runs the service named "hello". There should be a separate compose file for each set of things that are run together. That would make the compose projects useful and focused on a particular demonstration or use case. Currently, that compose file is an omnibus of services demonstrating various ways of running the two containers and a few supporting server apps for testing or demos. It's too confusing this way.

---

<div class="post-metadata">

**Author:** ![qrkourier](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/qrkourier/32/52_2.png) [@qrkourier](https://openziti.discourse.group/u/qrkourier)\
**Post date:** [January 6, 2023, 4:20pm UTC](https://openziti.discourse.group/t/tunneler-container-update/959/5 "2023-01-06T16:20:47Z")

</div>

> [@gooseleggs](#):
>
> I feel it is a shame that you are going away from the `ziti-edge-tunneller` name

The idea behind this newer container is that it's name reflects the use case (hosting with Ziti), not the name of the executable (`ziti-edge-tunnel`). The old container is still the most generic way to run `ziti-edge-tunnel`. I imagine that we might eventually roll additional tunneler-use-case-centric containers that inherit from either of these two container image lineages.
