12 KiB
dev diary
2018-03-29
@dinosaur
- setup ButtCloud.org and various linked services (GitHub, Docker Cloud, Twitter, Gmail)
- started
buttcloud/metarepo to store any meta information (including these dev diary entries) - started `buttcloud/butt-landing to be a simple public landing page for pub servers
- working towards a multi-service pub using Docker Compose, i realized
ssb-viewerandgit-ssb-webwere non-trivial to install in typical environments - the plan is to use this as a simple secondary service to get a multi-service pub working, then later can focus on the other secondary services
- working towards a multi-service pub using Docker Compose, i realized
2018-03-30
@dinosaur
- made Docker image for
buttcloud/butt-landing - extracted minimal peer server and client code from
scuttlebotintobuttcloud/butt-peer- added custom logging plugin which uses
pino, to try and have a consistent logging system across services - made two Docker images, one for
butt-peer-serverand one forbutt-peer-client- i combined them so i could use the client code in the server healthcheck
- added custom logging plugin which uses
2018-04-03
@dinosaur
- started
buttcloud/buttasdocker-compose.ymlof peer server, landing server, and nginx proxy - update
butt-peer-serverandbutt-peer-clientto not usenodeuser, easier to start with defaultrootuser- why? i ran into an error with volume data permissions, would rather punt to later
- UPDATE: changed this back, got it working with
nodeuser, needed to create volume inDockerfilethen mount external volume at same path
- update
butt-landingto auto re-connect to sbot, so it doesn't error when sbot is not yet up- why? this is the recommended way to have docker services depend on each other,
docker-compose.ymlv3 not longer supportsdepends_on: condition: healthy
- why? this is the recommended way to have docker services depend on each other,
- setup Docker Hub automated builds to build tagged images based on git version tags
- match tag name:
/^v[0-9.]+$/, docker tag is same
- match tag name:
2018-04-04
@dinosaur
- got minimal
buttcloud/buttworking! - iron out some kinks...
2018-04-08
@dinosaur
- switch to focus on Docker Swarm
- change to use Traefik instead of Nginx Proxy
2018-04-09
@dinosaur
- keep trying to get the Swarm setup to work, grr...!
2018-04-13
@dinosaur
- take a break from Swarm for meow
- first pass at scaffolding
buttcloud/buttcloud-provider- have a working web server, browser app, and worker, but not yet complete to start feature development
2018-04-14
@dinosaur
- more progress toward provider app scaffolding
2018-04-15 to 2018-04-17
@dinosaur
provider app has landed!
- integrate
redux-bundler - add emojis
- found seamless background image to tile on landing page
- start onboarding workflow
- implement start step of onboarding
- validate forms on client
- validate service calls on server, show errors in form
- show success or failure messages as snackbar
- after form submission (which creates the user)
- generate json web token that identifies user
- send welcome email to next page of onboarding with token
- emails are sent by queuing a delayed job to a worker (
node-resque) - setup decent email templates with
mjml
- emails are sent by queuing a delayed job to a worker (
- store user in local storage in case they refresh page before progressing
- show help text on page
- allow user to resend onboarding email
2018-04-18
back to the infra side, during breakfast this morning i figured out why buttcloud/butt was failing!
i had a hunch that it had to do with the address that sbot was binding to. i configured host as example_butt-peer-server, since that's how the Docker service was to be identified within the Docker network. but still, the health checker inside the service couldn't find it. i changed this to 0.0.0.0 and it works!
did the same for the landing service. now the stack comes online, you can curl -H "Host: example.butt.nz" localhost and get the output from the landing page associated with example.butt.nz (proxied by traefik).
next i added a custom plugin to butt-peer-server that allows you to configure externalHost, in case it differs from host. this means we can bind to host (like 0.0.0.0) but advertise our public multiserver address as example.butt.nz (like for invites).
then, on a whim from @mischa, i went back to buttcloud-provider to swap redux-form for final-form, easy as.
made up some issues, want to step back to think about the next steps from here.
also made the ButtCloud logo!
2018-04-19
- setup contributor license agreement: https://github.com/buttcloud/meta/issues/6
- setup kanbans
2018-04-26
- start to separate pub and hub stacks in swarm setup:
426deb39b9 - worked on deploy for web app demo: https://github.com/buttcloud/buttcloud-provider/pull/9
- browser code is up at: https://demo.buttcloud.org (using netlify for free)
- api server is up at https://buttcloud-demo.herokuapp.com/ (using heroku for free)
2018-04-27
- discovered and documented bug with
tinyify: https://github.com/browserify/tinyify/issues/10 - add standard style setup to web app: https://github.com/buttcloud/buttcloud-provider/pull/10
2018-04-30
- demo is now live! demo.buttcloud.org 🐑
- renamed sub-projects to either
buttpub*orbutthub*, to standardize language: https://github.com/buttcloud/meta/issues/7 - setup continuous integration for
butthub-provider: https://github.com/buttcloud/butthub-provider/pull/11 - setup ButtCloud account with OVH
- apply for their startup support program (for maybe $1k cloud credit): https://www.ovh.com/world/dlp/
- play with
docker-machineto create a local swarm across many machines- get the swarm scripts from
buttpubworking, now across multiple virtual machines
- get the swarm scripts from
2018-05-01
started docker-up: opinionated glue to manage our Docker swarm
2018-05-02
continued with docker-up
- ended up making a fun little continuable (
cb => {}) based async flow control library in./util/async.js, maybe will publish asflowstep - realized that the Docker API doesn't handle the
docker stack *functionality, that's implemented in the Docker CLI- i learned that a "stack" is really a set of networks, volumes, and services each with a label "com.docker.stack.namespace" to reference the stack name
- have to decide whether
- a) to continue using the Docker API and implement that functionality ourselves
- b) to move to using the Docker CLI
- for now, will go with option a) !
- reading the Docker CLI code, it's not scary or complex
- this way we have more low-level control of the Docker Swarm
- this way we can focus on exactly what we need for ButtCloud
2018-05-03
more docker-up, getting close to v1! 🎈
- add executable cli
- clean up the api
- fractal stacks!
- top-level config is a stack, with stacks all the way down
- each stack has services, networks, volumes, AND NESTED STACKS
- each stack may have a name to namespace associated services
- pretty configurable logging
next up (notes to self):
- better cli (take in resource type)
- use explicit docker version in api requests
- add "com.docker.stack.namespace" label to be legit docker stack
gotta work with @Mischa on another contract meow, then Art~Hack!
2018-05-04
- reviewed @austin's sweet pull request to
butthub-provider: https://github.com/buttcloud/butthub-provider/pull/13 - completed the "next up" features for
docker-upin the previous entry
2018-05-07
- published
docker-up/util/async.jsascallstep, wrote up a splash of documentation 🚶♂️
2018-05-08
docker-up: add basic integration and unit tests usingava, clean up log and config wrappers using composable callsteps:29655b561b- cc @ike
butthub-provider: look into adding integration tests usingcodecept- not ButtCloud, but got sponsored by TickTack to improve
ssb-pub: https://github.com/ahdinosaur/ssb-pub/pull/10
2018-05-09
butthub-provider: end-to-end acceptance testing with codecept: https://github.com/buttcloud/butthub-provider/pull/14
2018-05-10
butthub-provider: battled some end-to-end testing dragons 🐉 : https://github.com/buttcloud/butthub-provider/pull/14- integrated the entire web app stack (api server, asset server, worker, and mailer) in the codecept process
- at the end of the tests, the process was hanging, who was still running?
- with some help from
why-is-node-runningand heaps of reading dependency internals, started the journey to find every remaining handle, gotta catch 'em all! 🐎
2018-05-11
butthub-provider: won the end-to-end test war: https://github.com/buttcloud/butthub-provider/pull/14- cleaned up every last handle, so the test process cleanly exists meow
- which means continuous integration now includes end-to-end server + browser tests! 🙌
- travis gives us a running postgres and redis database, how nice
butthub-provider: finish a boring dependency upgrade: https://github.com/buttcloud/butthub-provider/pull/12docker-up: https://github.com/buttcloud/docker-up/pull/4- the plan was to add update for services, but along the way i realized many things were broken:
- each resource uses a different identifier!
downshould check if resource exists beforeremoveupreturns output of inspect
- generic resource creator now takes:
namehasUpdate: true forservice, false otherwiseidField: network usesId, volume only hasName, service usesID`
- the plan was to add update for services, but along the way i realized many things were broken:
docker-up: add continuous integration tests: https://github.com/buttcloud/docker-up/pull/5 ✅- travis even gives us running docker to play with!
2018-05-15 - 2018-06-09
- am starting to finally understand some advanced fp (functional programming) concepts like monads
docker-up: investigate usingsanctuarydocker-up: port code to useramda,folktale,folktale-validations, andfluturedocker-up: re-architect how everything works- given next config, translate into docker api config
- fetch all current docker api config
- diff docker api current and next configs
- show diff to sysadmin
- if acceptable, translate the diff into docker api commands and run those
- rename
docker-uptogyne - rename ButtCloud to PeachCloud
- get example swarm working across 3 virtual machines using
docker-machineandgyne

