LCP Compose

Next Generation LCP development environment

lcpenv

  • a.k.a lcpbox
  • a.k.a lcp-in-a-can
  • a.k.a the thing that system integration tests use

born out of historical necessity

 

hard dependency on lxc

container runtime

LCP services predate our adoption of docker

treated more like a vm

  • All services run in the same LXC container
  • Provisioned and configured via puppet
  • Not ephemeral (mutable environment)

limited scope

  • Only used by integration tests in BGTMOO microservices
  • Developers still do feature integration on FT as opposed to locally which can shorten the feedback loop a lot more

Designing next generation development environment

made possible by lcp team finishing dockerization

no more snowflakes

dockerized services all the way

dockerized services all the way

goals

for running e2e integration tests

  • Reliably - LCP infrastructure reliably starts up/shuts down during tests
  • Predictably - Failed tests can be reproduced across environments
  • With agility - checkout project and run integration tests on any code (including the latest) w/o rebuilding lcpbox

for understanding/experimenting with the lcp stack

  • Debug - devs should be able to run all services in the LCP/BGTMOO stack locally, set breakpoints and step through the code
  • Inspect logs - including aggregated logs, and trace transactions through correlation ids
  • Extend - running storefront, console, loyalty wallet locally
  • Onbard - bringing new devs up-to-speed on our platform and core products

for faster feature turn-around / prototyping

 

  • Rapid prototyping
    • elasticsearch 5
    • couchdb 2
    • prometheus
  • Local Testing
    • No FT deployments required to test new features
    • No FT race-conditions

lcp-compose

successor of lcpenv

design principles

as command-line interface tool

not as a library/framework

  • All features as exposed as sub-commands, not as APIs
  • Transparent
    • It's clear what a certain step is achieving
    • Can be replayed easily
  • Straightforward Integration
    • Clear setup/test/teardown as independent steps
  • Difficult to misuse/abuse
    • Discourages subclassing/abstraction
  • Language-agnostic
    • Wallet or PIE can use it too!

built on top of docker-compose

  • Utilize the plumbing docker-compose made available
    • networks, volumes
  • Can define our own configuration to describe Points-specific services under d-c
    • Generate docker-compose file from service definition
  • Extra control on lifecycle of the service
    • e.g., lcp-compose up does services availability check using custom labels

types of services

Infrastructural Services

  • Message Broker (rmq)
  • Data Store (couchdb, ES)
  • Logging (splunk)
  • Networking (dns)

core services

aka @TheRealLCP

  • gateway
  • security
  • platform_core

pluggable services

  • Buy
  • Gift
  • Transfer
  • Move
  • Orders
  • Offers
  • Storefront (?)
  • Loyalty Wallet (?)

service management

managed vs unmanaged

Managed services

  • Service whose lifecycle is controlled by lcp-compose
  • Can either be built from source code or run from an existing image
  • Can become unmanaged using `lcp-compose unmanage` command
  • By default, infrastructural services and core services

unManaged services

  • Services whose life cycles are managed out-of-band
  • But they can be configured in lcp-compose so they can be "discovered" by other services
  • Great for development/debugging
  • Pluggable services by default are unmanaged
  • Can become managed using `lcp-compose manage` command

service configuration

  • Service catalog is stored in the config file
    • service urls / build instructions
    • metadata of the project
  • Service configurations are rendered from templates
    • templates are stored in individual services, and part of the docker image
    • lcp-compose extract them from the image and templatize them

states and workflow

state: initialized

  • lcp-compose init
  • Generate a local folder .lcp-compose
    • store the initial lcp-compose config
    • generate docker-compose.yml from config
    • create service configurations folder
    • create logs folder

workflow: manage/unmanage

  • lcp-compose manage SERVICE ARGS
    • lcp-compose manage buy --image-id ...
    • configure buy service to use the specified docker image
  • lcp-compose unmanage SERVICE
    • lcp-compose unmanage buy --url http://192.168.0.100:5000
    • remove buy service from docker-compose file
    • registers buy service at http://192.168.0.100:5000 so other services can reach it by that url
    • run buy service locally yourself
  • Updates the config and re-generate docker-compose.yml

state: configured

  • lcp-compose config
  • Obtain the images for the services declared in docker-compose.yml
    • Pull image from registry or build image from source code
  • Create containers and extract the service configuration template from the containers
  • The config templates are rendered and stored .lcp-compose/
  • docker-compose.yml is updated with the location of the service configuration files

workflow: up

  • lcp-compose up
  • Implicitly calls `config`
  • Differs from `docker-compose up`
    • Figure out the service topological order using the dependency graph
    • Perform service availability check to ensure all dependencies are up before starting a new service container
  • Optionally perform sanity tests on the whole stack

state: started

  • All managed services are properly started
  • All service containers are addressable by their service name on the host
    • e.g., http://gateway, http://security
  • All logs are available for tailing `lcp-compose logs`
    • Also, Splunk!

workflow: down

  • lcp-compose down
  • Stop and remove all containers
  • Remove the docker network
  • Optionally remove all named volumes
  • Back to configured state

workflow: clean

  • lcp-compose clean
  • Delete generated service configurations
  • Optionally remove lcp-compose configuration and docker-compose.yaml

other commands

  • lcp-compose shell
    • starts a root shell on the service container
  • lcp-compose services
    • list all services and their configuration
  • lcp-compose attach
    • attach to a running service container
  • lcp-compose graph
    • show the current service dependencies

demo time

road ahead

migrate

  • Services to move from lcpenv to lcp-compose for integration tests
    • Remove hard-coded lcpenv URLs
    • Use mountebank as stub server so they can be managed by lcp-compose - easier test setup
    • Use Orders/Buy service as references
  • Services to own and maintain their configuration templates
  • Services need to be able to bootstrap itself (initial data seeding, setting up user, etc)
  • Move away from mounting /config, favour generating config from envfile

enhance

  • Incorporate other products and front-ends as needed
    • loyalty wallet
    • storefront
    • console
    • jreports
  • lcp-compose Postman collection

code repo

Use Github issues for feature requests

https://github.com/Points/lcp-compose

Documentation

https://points.github.io/lcp-compose/

Made with Slides.com