-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Installation documentation #44
Conversation
Includes content also delivered in systemli/ticker-admin#207 & systemli/ticker-frontend#187 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this important contribution. I add some thoughts about the installation and serving the api.
Also I would suggest to add a directory docs
where you can put this files in and add a reference to the Readme.
INSTALLATION.MD
Outdated
|
||
1. `cd /var/www/` | ||
The directory where we gonna install all the things | ||
1. `git clone --recurse-submodules https://github.com/systemli/ticker` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would not suggest to build the service on the target machine and have build-essentials
or golang
installed. Instead I would upload the pre-compiled binary from the host where you trustful built it or if you trust Github and the releases you can download the latest release directly.
For development and testing this way is okay but for a production setup I would at least leave a hint here for the possible impact (compiler and build tools on a production environment).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm standing on the point that I need to trust the Host Machine, where I build the package the same way I need to trust my local machine. Otherwise I wouldn't store data like mail addresses from users on this machine.
In any case, I would download the same Code from the same source & compile it.
The difference in this part would be, that there's another angle to deploy it.
Furthermore, I foresee difficulties with different build env's.
I'm not quite sure, if I'm missing a thing, but maybe you could elaborate more. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After a second read, my text sounds a bit passive aggressive.
That wasn't my intention.. :/
I would highly appreciate input for this topic, because as stated multiple times, I'm not comfortable with code & best practice builds. Neither in Go nor JS.
I thought of this as the best way to deploy this, but maybe it's just the best way I know..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem. I thought a bit about the topic for this install guide and think it is more or less a "quick install guide" which reflect the idea on how to bring the ticker to production (e.g. Jitsi also provides a quick install guide). So maybe a rephrase would be useful to not confuse potential users. I mean if you want you can also use Apache, Caddy or whatever serves http traffic with proxying.
It is a basic security principle is to not have any tools/software on the machine which is not needed. So for example to run a compiled golang program you don't need the go compiler. For development/testing it makes sense to have some tools installed. If we assume that is a quick install guide or you have a notice that it is not necessary if you have the compiled binary installed it is okay for me.
In modern infrastructure you would use a reproducable way to ship and deploy your software to your machine (like Ansible, we provide a lots of roles to e.g. install Jitsi Meet). So another point to name it like quick install guide.
Example for a production way to install/deploy the ticker:
- Check if the desired version of the ticker is present (/usr/local/bin/ticker)
- Download the desired version of the ticker from a artefact store (e.g. Github Releases)
- Provide a SystemD Service Unit for the ticker (create a user/group, home directory, /etc/ticker, ...)
- Write the configuration file to the config directory
- Start the ticker with systemd
I hope I could clarify some points. And again, thanks for bringing this topic up and provide a first documentation for the ticker!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I extended the install guide a little bit, pointed out the other options in the build/deploy process (build on your local machine, get it from github releases) & added an example nginx ssl conf.
Plus I added a quick service example file in the docs and referenced them in the install guide.
@0x46616c6b If you're fine with it, I would change the other docs (INSTALL_ALL & ticker-frontend / ticker-admin accordingly :) )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@0x46616c6b please take a special look at commit c6971dc where I rewrote most of the ticker-api deployment path.
This is how I understood your clarification, but I'm not 100% sure if it fits tightly to what you wanted to describe. :)
- Splitted the build and deploy part in multiple parts. - Pointing out the option to get the release from GitHub & to build it on your local machine. - Created a non certbot ssl example config
Hey @0x46616c6b. |
This pull request introduces an install guide for both, only the ticker api and a full set of
ticker
,ticker-frontend
&ticker-backend
usingnginx
as a reverse proxy andcertbot
to obtain free Let's Encrypt certificates.