Future plans

[dougbtv]

What is Bowline?

Bowline is tool to off-load your Docker builds to a "build server", one that provides continuous integration functionality -- and a front-end to a Docker registry.

Who is Doug?

I'm a linux and open source software focused developer and systems engineer who's been writing web applications since 1998. I began my professional career building custom CMSes, and working for an interactive 3d web start-up. I followed that by starting a business hosting images for blog users before the social networking boom, and later built software for managing hedge funds. The most recent last number of years, I've been working building custom applications for carrier grade VoIP / telecom solutions, including designing, developing, and managing resources for such projects. Currently, I am very interested in devops, containerization, and full-stack javascript development.

Initial pain points that inspired Bowline

• Trying to automate docker builds felt awkward
  • Trying to use Ansible to build/deploy
• Needed a private, and authenticated, registry
  • Building on each host was time consuming / expensive
• Information was in disparate places
  • Need to "tie together" a number of things:
    • The Dockerfile
    • The git repo
    • The result / logs of the builds

Initial goals achieved while problem solving

• Off-loads docker builds to remote host
• Alerts user of finished build
• Provides a "Go / No-go" result of build
• Detailed logs of builds
  • Uses web sockets for a real-time stream of builds in progress
• Authenticated registry
  • Compatible with docker login and docker push/pull

Initial accomplishments in addition to goals

• Collaborative builds
• Registry integration / registry front-end
• Already using bowline
  • Asterisk docker experiment
  • HA VoIP setup with CoreOS
• Continuous integration came naturally with logging and go/no-go
• Completely deployable with docker itself.

Future developments

• "deploy hook" to make action after build
  • create a continuous deployment paradigm
• better social features
  • favorite knots
  • comments
  • privacy feature
• more explicit continuous integration
• "multi container unit tests" -- test with an ecosystem instead of a single container
  • Some tests are incomplete when you can't integrate multiple systems, e.g.:
    • database / 2+ web apps or micro services / http server / message queue
• "distributed build server architecture"
  • extend Manager to be aware of multiple boxen
  • use an MQ for it (or etcd)
  • make builds "sticky" to a box that has it's cache.
• central auth
  • adapt to LDAP, etc.

Potential barriers to adoption

• using an SSL certificate
• central auth

Current issues

• privacy features in-work
• UX flow for new knots is too verbose
• pure git implementation is incomplete (github complete)
• build status UX needs to be groomed, has two phases which is unnecessary for users to grok