Open gordonbrander opened 7 years ago
Alternatively, could host the UI in a publicly available CouchDB install, then replicate the whole thing.
Unlike the Node tool, the Python tool for couchapps is pretty specific about the directory structure required. This is unfortunate. It also has a lot of project scaffolding features we don't need.
We don't need to do much except put a few files as attachments. I'm going to look into whipping up a quick Python script.
@LeonChambers I've created a tool to push a folder full of files to a design document. The idea is to make installing the UI to Couch part of the setup process.
During install:
tmp
dirtmp
dir.Do you have any strong feelings about that?
I wrote something similar here as part of openag_python
to load the design documents from the repo. It doesn't handle attachments though. It would be nice to merge these two things.
But I'm definitely fine with this strategy in general.
@LeonChambers Yeah I saw that. I thought it might be useful to extract this into a general utility that can handle attachments + views, lists, etc.
Have you looked into couchapp? It also seems to do exactly what we want. I'm not sure we need our own utility for this.
@LeonChambers extensively. It requires an opinionated directory structure that I'm not wild about -- would require restructuring the UI build stuff. We could go that way, but since we already have similar requirements for openag_python, I thought it would be good to have them go through the same codepath.
I don't have a very strong opinion about this, but the code to push to CouchDB is trivial. couchapp adds a lot of bells and whistles we don't use like project scaffolding.
Ok, that makes sense. Then I guess the next step here is to modify openag_python to use this new tool so that we don't have duplicate code.
@gordonbrander and @LeonChambers, have you guys considered approaching this as part of using a configuration management tool to build a project-wide deployment system? SaltStack seems like a perfect fit.
Compared to building more custom scripts, using SaltStack would let you manage things at a higher level of abstraction with more flexibility, repeatability, and readability. Most--perhaps all--of the building blocks you'd need to make the PFC2 setup process automatic and versionable are already implemented. Also, a big benefit is that better automation reduces the need for extensive documentation.
Here's how I'd go about writing salt states to build and deploy the CouchApp on a development workstation:
nodejs
, npm
, and nodejs-legacy
packages are installed.grunt
.OpenAgInitiative/openag_ui
into a non-temporary directory, or, if the directory already exists, to do a git fetch
instead. States are just YAML templates, so it's easy to use variable substitution to specify the branch or revision git.latest
should use. Leave the cloned directory in place so the state will run faster the next time around.openag_ui
into static files.grunt couchapp_deploy
.If you want to see what salt states look like for a simple deployment system, here's some stuff I made last year for setting up a minimal web app with nginx on a Debian 8 gcloud instance:
@wsnook this looks very cool, but it also looks tailored to the problem of cloud servers. Do you have insight into how it would look to use for setting up a Raspberry Pi?
...looks tailored to the problem of cloud servers
Right... I'm guessing you're referring to how my example used separate master and minion servers. I should have expanded on the "masterless minion" part that I just mentioned in passing (see masterless quickstart docs).
First, salt jargon is weird, so here's a quick glossary:
Basically, masterless salt on a Raspberry Pi would look like:
/srv/...
on the Pi minion instead of the non-existent master.sudo salt-call --local state.apply foo
on the Pi minion instead of doing the cloud style sudo salt <target_minion_id> state.apply foo
from a master.SaltStack's architecture is based on a message bus. On any host managed with salt, there's a minion process that can manage the host by "applying" states--conceptually it's more declarative than procedural. The minions can join a master's bus and get information about which states to apply when from that master, or the minions can have their own state files. Normally messages to the minion process arrive over the network, but you can also send them locally with salt-call
.
Oh, and for how masterless salt could be used to manage the whole OpenAg stack, I'm envisioning something approximately like:
This PR made it possible to host the UI as a couchapp on the Raspberry Pi https://github.com/OpenAgInitiative/openag_ui/pull/127. You can push the built UI to any CouchDB install, and it will be hosted and delivered by couchdb. The only thing left is to figure out a deploy strategy for automatic install.
Here's an initial idea... Add the following to the install script:
This still leaves the question of what to do for Docker. Make it part of the Docker install script? Maybe we keep the dist dir around and push every time?