Develop and document release process

[ssoloff]

In order to debug triplea-game/triplea#2603, we need to make some changes to the MARTI code. AFAIK, there is currently no official release process. In the past, code changes have simply been made in production without being configuration managed. Now that the code is under source control, we need to develop and document an appropriate release process.

I believe the following tasks need to be performed to address this issue:

• Document the current process for making changes to MARTI in production (e.g. stopping nginx, updating MARTI code, starting nginx, etc.). (@RoiEXLab)
• Determine what changes are necessary to inject the MySQL connection settings as environment variables so that they are visible to the new MARTI code that does not hard-code this information. (@ssoloff)
• Develop and document a new release process for MARTI based on a particular Git tag in this repo; possibly write a script to automate it. (@RoiEXLab, @ssoloff)

While MARTI is slated for retirement soon due to the new Node-based dice server, we will need a similar release procedure for it, as well. Therefore, this exercise needs to be done sooner or later.

@RoiEXLab I'd suggest we simply use the wiki for documenting the current and new processes to keep things simple. Let me know if you'd prefer something different, such as hosting the docs in the repo.

[RoiEXLab]

@ssoloff The procedure for updating MARTI code is non-existent.
Due to the nature of PHP there's no need to restart nginx when simply changing contents of a file. Reload the page in the browser and the updated php file gets processed.
The only reason to restart nginx is when doing some changes to the config (which is the place to exclude certain file types from being displayed if IIRC)

[ssoloff]

@RoiEXLab Got it. So deploying MARTI should be as simple as expanding an archive into the /dice folder on the server? I suppose it may be a little more complicated in that we need to ensure files deleted in the repo are also deleted on the server, but without deleting generated files such as the encryption key.

Also, what are the permission requirements on these files? I see a mix of files being owned by root and bung. Is using the www-data UID and GID sufficient?

You bring up a good point about the nginx configuration. We should probably store that in source control, as well. Can you document (in this issue should be fine) the command required to reload the nginx configuration after it has changed? Is it systemctl reload nginx or service nginx reload on Ubuntu?

[RoiEXLab]

@ssoloff

So deploying MARTI should be as simple as expanding an archive into the /dice folder on the server? I suppose it may be a little more complicated in that we need to ensure files deleted in the repo are also deleted on the server, but without deleting generated files such as the encryption key.

Correct, that's probably the biggest + for PHP ^^
Way too easy to setup, also the biggest problem, because it's basically individual scripts that can only reference each other if neccessary, but can't act as the same application.

Also, what are the permission requirements on these files? I see a mix of files being owned by root and bung. Is using the www-data UID and GID sufficient?

Legacy problems, I think www-data should be sufficient, but we should probably verify the file with passwords in it have stric read permissions, but no idea, never thought about it, as long as it worked.

You bring up a good point about the nginx configuration. We should probably store that in source control, as well. Can you document (in this issue should be fine) the command required to reload the nginx configuration after it has changed? Is it systemctl reload nginx or service nginx reload on Ubuntu?

Both systemctl reload nginx or service nginx reload should work, the use of the latter one is discouraged, because it's basically a legacy command mapping to the correct systemctl command, I use it anyway ^^

EDIT: There's no reload option for the service command. You need to use restart instead

[ssoloff]

@RoiEXLab I'd like to get /etc/nginx/sites-available/tripleawarclub.org under source control in preparation for deploying the updated MARTI (and just to have it versioned as a best practice). It seems the logical place to put that is in the triplea-game/tripleawarclub.org repo. Is there a better repo for it?

I'm pretty sure that repo semantically represents the tripleawarclub.org website, not the entire server. In which case, I was going to store the nginx site configuration in the repo at /nginx/tripleawarclub.org rather than try to mirror the absolute path on the server.

To ease updates to the configuration in production, it would be nice to set up the /etc/nginx/sites-available/tripleawarclub.org file as a symlink to the appropriate file in a local Git repo that maps to triplea-game/tripleawarclub.org/nginx/triplewarclub.org so we can deploy configuration changes with a simple git pull. Per the Linux FHS, I'm guessing the right place for such a local repo is under /srv/git/whatever, which would have to have the appropriate permissions to make the configuration updates seamless (most likely owned by group www-data, which we would all need to belong to just as bung is).

[RoiEXLab]

@ssoloff

It seems the logical place to put that is in the triplea-game/tripleawarclub.org repo. Is there a better repo for it?

Probably not, however what you probably should do is split the configuration file up in to independent files, you can do that, because the file contains 2 server blocks, one for tripleawarclub.org and one for dice.tripleawarclob.org
This should be done along with moving the dice root directory into a seperate folder like /var/www/dice.tripleawarclob.org which would make clear the 2 systems are completely seperate from each other.
This would also allow us to easily shut down tripleawarclub.org independentl of MARTI
However I'm not sure if it's practical to store a config file in online versioncontrol as the content is very system specific.
What we could do of course is having a local only git Repository for the config files unrelated to the actual software.

[ssoloff]

@RoiEXLab

what you probably should do is split the configuration file up in to independent files

Good idea. I'll do that once the current configuration is managed.

Do you see a problem with adding another virtual host to act as a staging server for testing MARTI changes before they are deployed to production? Something like dice-staging.tripleawarclub.org?

[RoiEXLab]

@ssoloff

Do you see a problem with adding another virtual host to act as a staging server for testing MARTI changes before they are deployed to production? Something like dice-staging.tripleawarclub.org?

Not a problem, we just need to add another DNS entry for that domain, and update the cerbot configuration to generate TLS certificates for this subdomain.
I could do that in a couple hours if you want (or even earlier, if it stops you from working on it).

[ssoloff]

Thanks. No rush. Also, TLS is not required for what I'm doing, so you can skip that if you want.

Segue question... Do we have documentation for what you're about to do? 😄

EDIT: Actually, don't worry about adding the subdomain for now. I'll just access it via http://www.tripleawarclub.org/dice-staging. I think that will force an HTTPS connection, but I don't foresee that being a problem since the TripleA client now supports HTTPS.

[RoiEXLab]

@ssoloff

Thanks. No rush. Also, TLS is not required for what I'm doing, so you can skip that if you want.

Not going anywhere without my free TLS 😄

Segue question... Do we have documentation for what you're about to do? 😄

Cerbot is just a comman-line tool, documentation for various linux-based systems can be found here. All it does is validating you own a domain, by placing a random token in your server root directory and checking if this token can be accessed online, and if so generates a singed certificate on your machine.
Getting certificates has never been easier 😄 (A shame there's nothing similar for code signing)

I think that will force an HTTPS connection

It will, yes it's going to work ^^

[RoiEXLab]

@ssoloff
And well the DNS entry is added via the namecheap online interface dan and myself have access to.

[ssoloff]

Item (1) is resolved by a wiki page that documents how to update the Nginx configuration via a configuration-managed process.

Item (2) is resolved by the new Docker environment submitted in #4, which documents how the DB connection information is injected by including a new FastCGI parameters file in the Nginx configuration. This pattern will be deployed to production as part of item (3).

[ssoloff]

Item (3) is resolved by the instructions in the bin/README.md and config/nginx/README.md files, along with the files that support those instructions.

This process has been used to deploy the new staging server. It will be extended to the production server in the near future.