High level "taxonomy"

/

• The Environmint entrypoint/landing page
• Dashboarded widgets from the suite
  • Running builds in DT
  • Recent failures from RT
  • Recent changes from DG
  • Compliance status from Mintspec
  • ...
• Links through to the other aspects of the suite
• Single auth/user implementation...
• Microservice/standalone UI that then links to APIs (straight from the UI) from other aspects

/api/...

• Blessed APIs
• Start documenting (with Swagger?)
• Forwards API requests to pertinent app/service, eg:
  • /api traversable API doc
  • /api/catalogueitem - DT
  • /api/cataloguejob - RT(?)
  • /api/node - chef-shim
  • /api/driftreport - DG
  • /api/spec - chef-shim(?) (mintspec...)
  • Big map of paths in Tier 1 (template in?)
• ​Support Basic Auth or JWTs? -- /api/login
  • ​JWT to facilitate more involved permission model​
  • Auth enforced by tier 1 - info available to BEs
• Apps can use their relative API addresses (eg /console/xyz but it's also available as /api/console/xyz)

Other aspects

• /admin
  • Global admin - eg Users
  • _No_ specific admin
  • Features, incl /api/feature
• /console
  • Console/DT...
• /driftguard
• /mintspec (or /compliance)
  • Do we need this to be standalone?
  • Possibly trend reporting etc...
  • _Possibly_ rule mgmt?
  • Download rules (and run manually)
  • Point mintspec at a new/unmanaged host?
• ↓

Other aspects

• /appdeploy
  • Appdeploy status UI (RO)
  • /maven
    • Maven repo for appdeploy artefacts
•  

Structure, on disk

/environmint

• /logs
• /services
  • Runit/S6
• /{start,stop}.sh
  • Starts/stops runit/s6. That's it.
• /web
  • Tier1 - SSL, config
• /{dt,chef-shim,rt,dg,sandbox,appdeploy,...}
• /sockets
  • Use Unix sockets rather than ports
• /db
  • One SQL db instance?

Software

• Caddy
  • Super simple - one excutable; one config file
  • Can LetsEncrypt or self generate certs
  • customer.mintpress.io
  • HTTP2
  • Consider OpenResty as our needs become more complicated/advanced
• Consul
  • Consul + Vault for secure info?
  • Allows for microservice
  • Behind an option of "[ ] make it secure" with a note saying "you'll need to unlock/manage the store"
•  

Software

• Ruby - in particular with a mind to Chef
• Java/Groovy - (Grails), Spring Boot
• Node.js - UI rest-y stuff
• Is it worth deprecating OracleDB internally?
  • ​Licence/ease...​
  • MySQL, Postgres?
• Is it worth considering deprecating Bamboo?

Process supervisor

Why use a process supervisor?

• Facilitate microservices (or, some separation)
• Facilitate _some_ language agnosticism, eg:
  • Java for Oracle stuff
  • Ruby for Chef stuff
  • Node.js for REST/UI-focused stuff
• Cleanliness: No more `nohups`
• Service restarts
• Only activate services that are enabled:
  • eg, `mintctl` only links the mintspec service if mintspec is enabled via the licence
  • _Could_ consider socket activation
• Only one entrypoint for a customer/user:
  • ​Run `/environmint/{start,stop}.sh`
    • Starts: DB, tier 1, all pertinent services.

Runit vs S6

• Runit is (or seems) a little more popular
• Chef use Runit
• S6 came along later and improves on some process handling
• S6 can do socket activation
• S6 is more powerful, but also more complex
  • Using a simple subset might be the way to go (initially)
• Both written in C. Both compile to static executables (with Musl) -- hence really good Linux support.

TODO

• Build and package:
  • S6
  • Tier 1:
    • v1. Caddy
    • vFuture. Openresty
• New Installer
  • Inquire.js
    • Design the questions
    • Deprecate individual installers
    • Output (to JSON)
    • Run Chef-Solo
    • Integrate with what JJ's done
    • Setcap Caddy based on answers, or note the port won't work (and the alt port) if not possible
  • mintctl tool/functionality

TODO

• Migrations
  • Strategy for managing data migrations
    • In particular SC items
  • Do we:
    • Make all updates idempotent, and rerun on every startup? Or config?
    • Handling inside the app seems nicer; hence every startup?
      • A la rerunable liquibase?
      • "Repeatable migrations"
• Version handling:
  • Is it just one external facing version for the suite, and the app versions are "whatever"?

Roadmap new features

• High level things, eg
  • "Some kind of alarming thing"
  • Build based on customer demand
• Consult more broadly for ideas and interest
• Start prioritising as time permits

Install

1. Provided with required artefact
   • Feels like a single script
   • Same tool as ongoing config. Aware that nothing is installed yet, and tweaks flow accordingly.
2. Runs installer steps for EnvironMint...
   • Asks for licence and confirms desired features
   • A little sales-pitch-ish about features eg
   • Main installer installs and configures all deps
   • Option to get `customerX.environmint.io`
     • Let's Encrypt cert
     • Useful as an Apex record for internal?
     • Simplifies internal IT reqs?
   • Self bootstrapping Chef run

3. ↓

Install

3. Tell Customer some key details:
   • Urls
   • Possibly a demo access key? (for APIs)
   • Suggests a tutorial...
4. Customer starts doing the tutorial...
   1. Creates a Weblogic (and deploys a war?
   2. Scales it
   3. Applies a patch
   4. Rolls it out
   5. Changes some config
   6. Rolls it out
   7. Pushes it back into mainline?

Upgrade

• Magic land: facilitate auto updating
• Message in UI - upgrade available
• Ops user runs `mintctl`
  • Asks whether to do upgrade or whether the user is doing something else
  • Offers to show release notes (primarily important ones; all available)
  • Gets any config input required from the user
  • Confirmation and go