Building controller

1

For most part my requirement is to build tunneler on openwrt which work fine. Just wanted to make sure that I'm familiar with the eco system and able to made changes/compile different components if needed.

Following this builds ziti cli package, are there similar instructions to build controller or fabric modules?

2

ziti version
NAME VERSION
ziti v0.0.0
ziti-controller not installed
ziti-prox-c not installed
ziti-router not installed
ziti-tunnel not installed
ziti-edge-tunnel not installed

This means with the new reorganization of new code, other packages not being shown as not installed doesnt matter. Just go install ./ziti will do? If I make changes in controller directory, then do go install again and then run ziti controller run, my changes seem to take effect. Just trying to confirm whether my understanding is correct.

3

Hi @pearl

You are correct, all you need is the ziti executable. We're still tidying the CLI up a bit. The version sub-command output is confusing. Running ziti --version will show you the version of the ziti executable you're running without the confusing bits. One of the things planned for the next pass on the CLI is removing (or at least hiding) the duplicate version commands.

Let us know if you have any other questions.
Cheers,
Paul

4

What happens once you have the "ziti" executable built? There aren't any instructions on how to build the other executables that one thinks would be needed (controller, router, etc.). Do you then use "ziti" to build / download them? I read the markdowns in the "doc" directory but didn't see anything obvious on what to do next. I'm building using the local w/o Docker option. Thanks for any help on this.
cc: @TheLumberjack

5

ziti executable is one for all. If you type "ziti --help" it will show you all the details.

6

Thanks, James. Yes, "ziti --help" shows you all the multitude of things the "ziti" executable supports. But even before that, since I'm not familiar with how to set up the system, what is the next step in setting it up? Is it to set up the controller? Set up network? Set up router? The documentation on the main site shows how to do "expressInstall" but I would like to do so step-by-step, from the ziti executable that I built from source. Is there documentation / tutorial on how to do that? I didn't see it from any "Readme's" from the ziti repository source.

7

Hi @jnguyen-us .

I think these links will help

I think those should answer your questions, hopefully. :smiley:

8

Thanks, @TheLumberjack. This is getting somewhere.

It appears all three links / options require the use of an external bash script. Which of those methods would you recommend as the best? Should I use "from-scratch.sh" from your own repository or "ziti-cli-functions.sh"?. Also, why is the "ziti-cli-functions.sh" script (part of the " Local - No Docker" option) is not in source control? It seems useful enough and should be part of a project that contains it.

9

None of the links require you to use bash but you surely must understand it in order to follow along. It only requires the ziti CLI itself. You can run all the ziti CLI commands on your own as shown in this gist and on that ziti tv and as discussed in the other discourse thread.

As for the "recommended" approach, if you're looking to learn, reading/understanding the ziti cli commands that the bash script automates/executes is invaluable imo.

If you're looking to install in "production" - there are guides being worked on that you should probably look / review over here Deploying to Production | OpenZiti - those should help

10

I get that bash is not require. However, using the shell scripts allow you to follow what it's doing (installing, configuring, provisioning, setting up, etc.). So in that way, you're right, it's helpful for learning.

I'm looking to build and install from source. I wonder if some kind of official project (say for a DevOps team) will be created that includes scripts or playbooks (in bash, Python, Terraform, or Ansible, or anything that is apt) to build the "production" / "test" environments. Right now, the scripts mentioned above grab a pre-built binary from somewhere else not from the resultant "build" directory in the source tree.