Add (or update) action to send a tag version to a machine

[bickelj]

One action should (eventually) occur automatically when a new tag gets created: send that tag version to the test machine. The same action should be able to occur manually for the production machine.

This builds on (depends on) issues #8 and #7.

[bickelj]

All the docs around https://docs.github.com/en/rest/guides/delivering-deployments and https://docs.github.com/en/developers/overview/managing-deploy-keys etc. seem to assume we'll install git on the test and production machines and have those machines pull. That is not where I was going with this but it may be the paved route. At the same time I see I might be able to add environment secrets such as ssh private key that grants limited access to the test machine. In other words, the expectation seems to be pull rather than push. Pull is probably safer than push. I suppose instead of looking for a local file the deploy.sh could instead look for a signal/file/flag in a remote location (e.g. the repo) without any cloning etc.

[bickelj]

But the even more dangerous push is not without precedent in the github actions list: https://github.com/marketplace/actions/ssh-deploy.

[bickelj]

I see it still does not meet the environment rules. I guess I need to remove the "main" branch restriction, because there is no distinction in git between tags and branches.

[bickelj]

https://github.com/PhilanthropyDataCommons/deploy/runs/7257974559?check_suite_focus=true instead used an approval restriction rather than branch restriction. There are still some loose ends, e.g. quoting around echoing to a file, the branch name not being quite right.

[bickelj]

While PR #20 improved it, there is still another element to add: trusting the host keys on the client side (in addition to allowing access on the server sides).

[bickelj]

I still get host key verification failed in https://github.com/PhilanthropyDataCommons/deploy/runs/7258968850?check_suite_focus=true despite updating the environment variable KNOWN_HOSTS with what ought to be a working value. Perhaps there is a marketplace action out there that helps, I see a handful.

[bickelj]

Hearing no objections to the design neither here nor in chat, I will try enabling ssh access for the build user and see if it changes the situation here.

[bickelj]

In order to push a build, I need to push a tag. To justify pushing a tag, I thought I would update the compose.yml. When testing the compose.yml I was puzzled that the proxy couldn't connect to the web service, but I think it is simply because the web service still listens on 127.0.0.1 instead of all interfaces. Edit: and indeed, specifying - HOST: 0.0.0.0 in the compose.yml makes it work.

[bickelj]

The order of the flags in the scp command is significant. Putting the -o options before the source mattered. The message was sent to the test machine successfully.

When trying to pick it up from deploy user, however,

$ ./deploy.sh 
docker-compose version 1.25.0, build unknown
docker-py version: 4.1.0
CPython version: 3.9.2
OpenSSL version: OpenSSL 1.1.1n  15 Mar 2022
WARNING: The PG_PORT variable is not set. Defaulting to a blank string.
Pulling reverse-proxy ... done
Pulling web           ... done
Pulling database      ... done
Removing network deploy_default
WARNING: Network deploy_default not found.
WARNING: The PG_PORT variable is not set. Defaulting to a blank string.
Creating network "deploy_default" with the default driver
Creating deploy_web_1           ... done
Creating deploy_database_1      ... done
Creating deploy_reverse-proxy_1 ... done
rm: cannot remove '/home/build/tag_to_deploy': Permission denied
$ ls -la ../build/tag_to_deploy 
-rw-r----- 1 build build 17 Jul 14 19:48 ../build/tag_to_deploy

The permissions need to be set for the build group to have write.

[bickelj]

Also set perms on the directory properly, that helps.

[bickelj]

I also updated the known hosts secret to use an explicit IP address rather than the hashed IP address, just in case that was the issue, before I had found the scp args order issue.

[bickelj]

The action is working but also needed a prod environment. I added the secrets required to connect to another environment here, but have yet to enable that in the script.

[bickelj]

Weird. I do not see a straightforward way to make this same GitHub Actions script work for two separate environments. I was hoping to change this:

    environment: test

into this:

    environment:
      - test
      - production

But no dice, that is invalid. Perhaps a comma or space separated list will work?

[bickelj]

Weird. The job had succeeded earlier today and now it failed. Did I accidentally update the Test env vars when I meant to update the prod ones? Unlikely.

[bickelj]

Test var: Updated 3 hours ago (and 6 days ago for others) Prod vars: Updated 1 hour ago

[bickelj]

The two jobs that succeeded were 2 and 3 hours ago.

[bickelj]

I tried again with the same tag (delete on GH, push again, successfully triggered the workflow), but it fails. These are failing with a different error now.

[bickelj]

The next thing to try will be to also include a matching public key file, that might help.

[bickelj]

Hmm, still not working. Scp is looking in the wrong spots despite being told exactly where to look.

[bickelj]

Authentication refused: bad ownership or modes for directory

[bickelj]

.ssh is 700, .ssh/authorized_keys is 600, but it is complaining about the directory above .ssh.

[bickelj]

Specifying a different directory for the tag_to_deploy should work. Trying that.

[bickelj]

This seems to be working. There are other improvements that can be made but I will make other tickets for them.