Jetmon: Dockerize app

[fgiannar]

First attempt at dockerizing Jetmon.

Testing instructions

1. Checkout branch
2. Create a logs dir under root and add the following files: jetmon.log, status-change.log
3. Create a stats dir under root and add the following files: sitespersec, sitesqueue, totals
4. Update config/db-config.conf [TBA once we figure out how to populate this file properly]
5. Hack (needs to be resolved or committed): Add #include in http_checker.h
6. Hack needs to be resolved or committed): Replace var _watcher = require( 'jetmon.node' ); with var _watcher = require( '../build/Release/jetmon.node' ); in httpcheck.js line 21
7. docker compose build
8. docker compose up -d
9. Monitor jetmon.log

Helper note to populate the DB (todo automate this):

1. docker compose exec -it mysqldb sh
2. mysql --user=root --password=123456 jetmon_db
3. Create jetpack_monitor_subscription table

CREATE TABLE `jetpack_monitor_subscription` (
		`blog_id` bigint(20) unsigned NOT NULL,
		`bucket_no` smallint(2) unsigned NOT NULL DEFAULT 1,
		`monitor_url` varchar(300) NOT NULL,
		`monitor_active` tinyint(1) unsigned NOT NULL DEFAULT 1,
		`site_status` tinyint(1) unsigned NOT NULL DEFAULT 1,
		`last_status_change` timestamp NULL DEFAULT NULL,
		PRIMARY KEY (`blog_id`)
	);

CREATE INDEX `bucket_no_monitor_active` ON `jetpack_monitor_subscription` (`bucket_no`, `monitor_active`);

12. Add some sites:

INSERT INTO `jetpack_monitor_subscription`(blog_id,monitor_url) VALUES (YOUR_WPCOM_BLOG_ID, YOUR_SITE_URL);

[fgiannar]

I thought about this a lot. Should the node addon (jetmon) be built during the image build? Should we approach it with multi staged build?
When I tried that the build folder was not added locally. Also since we are developing and using the addon here it seemed better to do so when we run the container 🤷
Could really use some confirmation on this approach though

[chrisbliss18]

I think the approach is good for now. I pushed up some changes that kept a similar approach that I'll discuss below.

[chrisbliss18]

I pushed up a couple of changes that should ease testing for now. It simplifies the testing instructions in the top post down to:

1. Checkout branch
2. docker compose up --build -d
3. Monitor jetmon.log

I added a run-jetmon.sh script that is run by the Dockerfile. It ensures that the needed directories are present and generates the key and cert if they are missing.

There's more refinements to make, but it should ease testing.

If these changes aren't wanted, I won't be hurt if some or all of them are reverted.

[fgiannar]

This is just a hack I did to overcome the parsing issues with db-config.conf, shouldn't be committed imo :)

[chrisbliss18]

Yeah. I waffled on that. It's weird to have the db-config.conf file in the repo at all isn't it? Usually confs like that are a local file system thing and not committed.

[fgiannar]

I was also hesitant to add this change till we make sure we are using the correct node and node-gyp versions.

[chrisbliss18]

I figured we could make adjustments once we get to see the production systems. For now, it makes testing easier without having to stash/unstash local changes.

[fgiannar]

I'd consider adding the logs and stats related directories and files on build instead :)
I'm still not sure these should be part of the image build though or it's better to create them on our local envs.
Same with certs.

[chrisbliss18]

I fixed that up in my second commit where I just ensured that both directories are part of the repo. At this point, the script just acts as a sanity check to ensure that the directories are present. I think it works better set up this way (as part of the repo by default) as opposed to some Dockerfile build step as the build process could result in directories that exist in the docker filesystem but not the local filesystem, which would make testing and log inspection more difficult.

We don't have to stick with the logic I added in the run-jetmon.sh script (or keep the script at all). I mainly wanted to throw it out there to show that we can launch using a script that contains whatever logic we want rather than being stuck with just running the npm command to launch the container.

[fgiannar]

Closing in favour of the most recent one (after merging the production updates): #8