Deploy Sockethub from the npm package #146
No reviewers
Labels
No Label
service
accounts
service
discourse
service
drone-ci
service
email
service
garage
service
gitea
service
ipfs
service
mastodon
service
postgres
service
remotestorage
service
wiki
service
xmpp
bug
design
dev environment
docs
duplicate
enhancement
feature
good first issue
idea
invalid
kredits-1
kredits-2
kredits-3
on hold
ops
question
release
major
release
minor
release
patch
security
ui/ux
wontfix
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: kosmos/chef#146
Loading…
Reference in New Issue
No description provided.
Delete Branch "feature/145-sockethub_from_npm"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is currently 4.0.1 and is set as an attribute. The recipe is very simple now, it installs the npm package, and the systemd service runs
/usr/bin/sockethub
and sets the environment variablesThis has been tested in a VM and deployed to nodejs-2. It should be deployed at the same time as a release of Hyperchannel that supports the new Sockethub
Closes #145, #91
@ -81,0 +57,4 @@
user: "sockethub",
group: "sockethub",
entry: "/usr/bin/sockethub",
environment: { 'DEBUG' => '*',
Aside from this being useful to be configurable as an attribute per node/role/environment, I think this should not use full debug logs in production.
I'm pairing with @slvrbckt in 2 hours, so I'll find out about the best config value here.
@slvrbckt Could you add a comment here perhaps about which log setting you think would make sense in production?
I would suggest
DEBUG=sockethub*
as a reasonable log level, as it will report on the core sockethub components (sockethub, platforms and schemas) but not the auxilary libraries which would increase verbosity a lot.Deploy Sockethub from the npm packageto WIP: Deploy Sockethub from the npm packageI'm having second thoughts about deploying from the npm package. What if we have to use a hotfix on a whim, because there's a security hole for example?
Perhaps a better way is to keep deploying from Git, so we can point the source to any repo or branch we need. WDYT?
@raucao wouldn't it be sufficient to just have a patch release of sockethub that you could update to?
Maybe. But you don't really want to have an official patch release immediately for every experimental or custom fix.
Also, there may just be general customizations that are outside of upstream scope. That's why we deploy most apps from our own repos and branches.
Changed my mind again. You're right, @slvrbckt, security patches should be released asap anyway.
Also, any customizations we have must be useful to someone else, so they should be part of the released feature set, except for testing/staging instances that we can deploy from source.
I'd just turn the systemd unit here into a native Chef resource, now that that's possible. And update to the latest release version, of course.
WIP: Deploy Sockethub from the npm packageto Deploy Sockethub from the npm packageThis is running on nodejs-2, with a haproxy rules on centaurus. I haven't switched the DNS entry yet (to centaurus' IP, 78.46.59.98), @raucao maybe do that just before you deploy the new Hyperchannel?
LGTM. 👍
Feel free to switch the DNS. I'll push Hyperchannel then.
Found a problem with the new setup: #333
The Websocket issue has been solved, but there's a firewall rule missing for port 10550, to be configured on Centaurus (so it's not overwritten by Chef).Edit: the firewall rule was there, but obviously not run the last time Chef was run against centaurus from
master
. m(