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

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

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

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/