Lighthouse Final Document
Contents
1. 13 are in fact the instances of Docker which run the application The actual process of updating an application is both time consuming tedious and error prone as the release manager must interface with each of the potentially hundreds of instances to manually perform the update one at atime With our application management features we provide a layer on top of this which allows the release manager to think of the application like a developer as a single entity Using Applications Creating an Application There s a first time for everything and the same is true for applications In order to get an application up and running all the user has to do is provide a set of Docker instance which will actually be running the application and the set of instructions telling the application what to do From here Lighthouse handles all the busy work of telling each instance to start running the new application Updating an Application Of course no application ever has a single version and some applications will take off faster than others To accommodate we let the user update their application in a very painless manner To update the code running in the application the user only has to provide a new set of instructions just like they did when they created the application Applications can be scaled up or down in an equally painless way the user only has to tell Lighthouse any instances they would like to add or remove from an application and Lightho2. implemented as a superset of the standard Docker Remote API allowing users to send specific Docker requests to their target platform as well as add new platforms users and other infrastructure configuration Host providers manage the actual startup and application runtime but are controlled via the Lighthouse main controller Provider interfaces are installed on each provider as part of the Lighthouse application and define a common interface for communication between the host network and Lighthouse Docker images are hosted on the Docker registry provided by the organization using Lighthouse Host providers are instructed to pull new images from the registry on application deployment Harbor has type and associated data Model Store emits change event Controller Polls model for new state on change event and pushes to view via scope Backend Figure 2 Harbor block diagram Two way binding still allowed here but cannot update state without first being transformed to an action typically through a Service Harbor s goal is to present the user with information and provide the user with a simple UI to manage their array of Docker installations Using the API exposed by Lighthouse Harbor renders the response from Lighthouse into HTML and displays it to the user Harbor must know how to handle any errors in communicating with the Lighthouse server manage user sessions for logging in and out and generate AP
3. This led to the creation of what we call Compilers These are drivers for a specific database that are capable of generating strings for their particular database With this method the user need only specify the Compiler to use and the databases package will load it and operate normally This was a much more modular design than we had originally created Beacon Implementation As already mentioned Beacons we not originally part of our end to end pipeline Once they were however there was some discussion about what their actual duty would be Because the ancestor of Beacon the provider driver had been developed inside Lighthouse it was partially tied to some of that functionality Our decision was how much of that functionality would migrate with Beacons and how much would remain in Lighthouse One proposal was to have heavy Beacons and make Lighthouse light What this means is that each Beacon would be capable of most of the functionality that Lighthouse currently provides and Lighthouse itself would mostly handle routing This method did help us abstract some functionality to simplify our implementations but was not very feasible as it would have required that each Beacon have access to its own database which was far too much overhead to have to be replicated across the many cloud providers the user may have Instead our implementation uses light Beacons which provide routing for a heavy Lighthouse essentially the opposite of
4. actors in the Lighthouse system release manager and IT admin Release Manager Functions 1 Login Authenticate 2 View currently deployed containers 3 Deploy and start a new container 4 Rollback a container deploy to a previous version IT Administrator Functions 1 Login Authenticate 2 Initialize provider with authentication credentials 3 Create and delete system users 4 View provider statistics and analytics Functional Requirements e Docker addresses o Description The IP address that are hosting Docker daemon publicly on port 2375 o Users Administrators o Actions add remove edit e Docker Images o Description Each Docker daemon has a set of images referenced by name or UID o Users Developers Administrators o Actions add remove edit e Docker Containers o Description Each Docker daemon has a set of running containers referenced by name or UID Containers are spawned from images pre existing inside a Docker daemon o Users Developers Administrators o Actions start e Arguments o exposed port o command o environment variables stop e Docker Analysis o Description Should be able to view running containers in real time o Users Developers Administrators o Actions view e logs e CPU usage e memory consumption e Authentication o Description Given an email and password all users can be denied or granted access to the webapp o Users Everyone o
5. the form Status OK Warning Error Starting Complete Finalized Method GET POST PUT DELETE Endpoint containe reate Message lt Warning Reason gt lt Endpoint gt Code Instance myInstance com 5000 v1 12 Item 0 to Total Total Figure 10 Streaming response general form The issue is that when Lighthouse sends out requests in a batch operation there isn t really any way of knowing in what order they will complete due to things like request latency or processing power of the destination instance Lighthouse does however know when it creates new batch request and when that request has completed For this reason the update stream is formatted as a series of blocks which begin with an update with status Starting and end with an update with status Complete The blocks in turn wrap a series of updates relaying responses from individual instances which will tell the client whether the block completed successfully or not Because many different requests will return a stream each requiring a different number of blocks there must be a way for the client to know that the request 15 is complete To accommodate Lighthouse sends a single update with status Finalized when the request is fully completed regardless of success or failure The client should only consider the request complete once this update is received An example of an entire up
6. time to get down to the nitty gritty of running everything e Lighthouse o cd SGOPATH src github com lighthouse lighthouse o docker run p 5432 5432 d postgres latest o GOPATH bin lighthouse databases reload 19 e Beacon o SGOPATH bin beacon token foobar h 0 0 0 0 5001 driver local Testing Now for everyone s favorite part testing e Harbor o npm test e Lighthouse o go test github com lighthouse lighthouse cover e Beacon o go test github com lighthouse beacon cover Playing Around Now that everything is happily running let s do some magic e Visit localhost 5000 login e Enter in your credentials o Default Email admin gmail com o Default Password admin 600 ds Lighthouse x YY gt GC ff D localhost 5000 login Lighthouse Email admin gmail com Lighthouse 2014 Figure 13 Logging in e Click Add Beacon and administer the following information o Alias Local Beacon o Address 127 0 0 1 5001 o Token foobar 20 000 Lighthouse x WN La a gt fi D localhost 5000 beacons e Alias Local Beacon O Light Address 0 0 0 0 5001 Token foobar Figure 14 Connecting to a Beacon Production Environment Preferred Operating System For all of these projects we recommend using any Linux distribution that runs Docker as the OS Throughout the project we favored CoreOS Setup Beacon Right now Beacon is configured
7. 9 Loc Ce 0 9 a a teen meee A dos 19 Software Requirements caia 19 Pulling the Source a Ee Gees 19 Installine DEPENAENCIES iii A NENNEN EEN 19 BUE A A ae ate See E A A A Ea cea 19 A dead 19 TOS IT 20 EVA e LL DEER 20 Production ENVIF OA MeENt Ll tt dt aii 21 Preferred Operating Veterans 21 SUB At 21 SETUP Lighthouses iii EA 22 8 Appendix ll Previous Verslons 23 Addition Of Beacon EE 23 Database Paradigms sce feces a a deet eege A Seet drett ege ege degen gece a 24 Beaconmlmplementathonss cc2efese eE aria a 25 Application Management oeira eaa ai a ai EO EEO aE aAa E E aaia 25 9 Appendix lll Other Copnsiderations nn nnnnnnncnanannnos 26 Single Page Application Architecture 26 Ane ularsS arid GO EE 26 Requirements Gathering ee coo 26 F t re Work a 27 10 Appendix V Table of Tabless ooo ii east 28 11 Appendix V Table Of Images eeh SEENEN EES csicedicssdadhde dE 28 Final Document v1 CprE 492 May15 17 1 INTRODUCTION Project Definition Within the past year Docker has emerged as an execution and deployment environment for distributed applications It supports standardized application installation and execution via containers built from a common template that can run on a variety of host platforms In the past the efforts to standardize distributed and scalable applications were focused on the virtual machine which was replicated across the desired host platforms Docker removes the overhead of hosti
8. Actions login e Arguments o Email o Password logout e Authentication Accounts o Description Admins should be able to control user accounts o Users Administrators o Actions add remove edit Non Functional Requirements Security System should be secure and not allow unauthorized control e Protect against o XSS attacks o session hijacking o unauthenticated requests o exposure of sensitive container server data e Only use HTTPS to mitigate various communication security exploits Code Quality should be easy to maintain and understand e Git Commit comments should be clear and concise standard commit conventions e Style Guides o GO m style guide m effective tips o JavaScript m style guide e Code reviews must include at least 2 other team members to be verified for master merge Functional Decomposition High Level Decomposition Cloud Providers Docker hosts Docker Registry Datastore Lighthouse Organization Hosted Organization Hosted Lighthouse Figure 1 System Block Diagram The overall architecture of Lighthouse is built upon the common client server pattern Users interact with the system via a single page web application that s loaded once into their browser with subsequent system requests made via a REST API over HTTPS utilizing JSON as the data interchange format Requests received from the web interface are routed through authentication and API control Our API is
9. I requests to Lighthouse Lighthouse local boot2docker Containers Cape Images Figure 3 An example of Harbor s Ul Actions Lighthouse Request Response To Beacon Request Response To Database ee Provider Interface Authentication Key API Routing Database Interface User Authentication Le A A A AAA A AAA A AA AAA Request Response To Front End Figure 4 Lighthouse block diagram It is Lighthouse s job to authenticate users cache Docker hosts from the provider interface and provide features on top of what Docker already provides such as rolling back deployments Lighthouse exposes a REST API described below that anyone can build off While we use it as a way to communicate with the front end the API allows for users to build easily build automation into their systems The back end communicates with provider interface s in order to discover any cloud instance that is owned by the user and running Docker It must also elegantly handle errors by returning a sane response to the client and log any errors or events that pop up Beacons Docker Containers i Cloud Service Cloud Service i Provider API Provider Detector Docker Container Discovery Lighthouse API Router Authentication Cloud Provider s Firewall Request Response To Central Back End Figure 5 Beacon block diagram 10 The beacon is installed within each
10. May15 17 Advisor Dr Mitra Lighthouse Final Document Client Workiva Version 1 1 Caleb Brose Chris Fogerty Nick Miller Rob Sheehy Zach Taylor April 28 2015 CONTENTS Ven CEET 1 1 UIMtrOdUcCtiON cier a dt a he 3 Project Definit OMe CCC O 3 ee Eo e td e ETTA 3 Definitions of Common Terms and Abbreviations nana cnn nn ran nn anna nc nancncns 3 2 DeliveraDlesiicasd aa a ia ia 4 LINO TO OUSC iii ged Segoe Renee ageet ee A Harris 4 BEACON NEE 4 DOGUIMENTATION cute o e da 4 E EE H DEE 5 System REQUIFEMENTS inicia iste stein EEN a e a Mista ides 5 E NN 5 Functional Reouirementzs iiser caoiersne niies eraai eai a eaaa ER AEREE E EEA sae EEEo a Es 5 Non Functional REQUIEM E 7 Functional D composition eee enaena ie dades 8 High Level Decomposition mesi a A id da adi 8 e EI EE 9 A ON 10 BEACONS Sesccsesects etter cseness ces e oe 10 4 DetailediDSSEnip ti Oates iaa 11 Interface S pe Cificationis cnans nakaa Veedel Veedel R 11 LighthOUSe A a aaa 11 e ll 11 Lighthouse and BEACON ue it 11 HDi a ia aa 13 Deployments and Applications c ccccccccsssssssssecececessesesaeseceeecesseseaaeaeceeecesseeeaesesececesseseaaeseeeessessessaaeass 13 Using Applications dias 14 Design and Implementatlon 14 Technical ISSUES uri ii ic 16 Why DO BEACONS Existe a iaa 16 Authentic ori As 16 Str eaMiN EE 16 Zeg le TE 17 6 CONGCIUSION E c tit de eee eA LIO Be he iS Ae AS EE 18 Tor ele ie tel ES HS gl ELE EE 1
11. ain Controller Server Backend ER Docker Registry Provider Management i API Routing repository SSH Datastore TECA Figure 15 First version with Beacons 23 Database Paradigms From verifying users to deploying applications a substantial amount of Lighthouse s operations rely on databases For this reason we developed a very extensive databases package which abstracted things like query generation and result extraction into one concise interface This helped to both improve codebase readability and reduce testing overhead However because the environment of Lighthouse was constantly being updated and this package was no exception At creation all tables that Lighthouse used were simple key value lookups where the key was always some string and the value was a JSON object The benefit of this implementation was just its simplicity there was only one column to query by one column that could be updated etc This method worked very well for things like users which would only need to be extracted by their emails However when development reached the implementation of Beacons we saw our first object that needed to be looked up by more than one value Beacon address or instance address and as a result we needed a more sophisticated architecture The second iteration of the databases package saw the addition of schemas Here an object would be added to the database by extracting each of it
12. cloud segment the user wants to access It allows us to use a single API on the back end to locate relevant cloud instances across all providers By being in the relevant cloud the beacon is granted access to privileged APIs allowing it to discover other instances owned by the same account 4 DETAILED DESCRIPTION Interface Specifications Lighthouse API The Lighthouse module provides a REST API as an interface between the UI and the back end logic This API exposes endpoints that allow clients to control Docker authenticate users modify users and permissions interact with beacons and manage applications The full API documentation is a bit large to fit here but can be found on GitHub under the Lighthouse organization Streaming Lighthouse s core functionality revolves around the batch processing of large deployments As the number of deployments scales up so does the latency of the processing The combination of multi threaded processing and incremental status updates becomes critical functionality as the instance count in a deployment reaches into the hundreds Lighthouse Applications Beacons Users Signed in as admin gmail com Y Updated testapp Pulling required image POST images create fromimage ubuntu latest Creating new container POST containers create name testapp_tmp Deleting old containers DELETE containers testapp force true Setting up new container POST containers testapp_tmp rename name testapp S
13. d hundreds of Docker instances to Lighthouse manually At the same time we were searching for a solution to make it easy for Lighthouse to communicate with hundreds of Docker instances This would also be tedious to set up if each Docker instance required its own static and public facing IP address The solution we designed was the Beacon module Authentication This issue arose in the middle of March 2015 Everything was coming together and we were about to get user management features online when two team members caused the Lighthouse authentication state and the Harbor authentication state to get out of sync This caused issues where Harbor indicated to the user that they were logged but Lighthouse had no recollection of this session The solution was to generate a notification on the server to automatically inform the client of its authentication state Streaming The idea for streaming status happened over a code jam when we realized Harbor had no way of indicating how far an operation especially a batch operation had completed before failing It was also 16 not possible to view status progress or logs without manually refreshing the page This contradicted our goal of having a quick response time for user interactions This issue was especially challenging due to the nature of HTTP responses While the protocol supports streaming the response and stream needed to work its way along three hops to the final Docker instance requiri
14. date stream is shown below Status Starting Method DELETE Endpoint containers my app Message Deleting old container Code 0 Instance Item 0 Total 4 Status OK Method DELETE Endpoint containers my app Message Code 404 Instance instance0 com Item 0 Total 4 Status Warning Method DELETE Endpoint containers my app Message No such container Code 404 Instance instance2 com Item 2 Total 4 Status Error Method DELETE Endpoint containers my app Message Code 400 Instance instancel com Item 1 Total 4 Status Error Method DELETE Endpoint containers my app Message host unreachable Code 500 Instance instance3 com Item 3 Total 4 Status Complete Method DELETE Endpoint containers my app L Message Deleting old container Code 0 Instance Item 4 Total 4 Status Finalized Method Endpoint Message Code 0 Instance Item 0 Total 0 Figure 11 Update Stream example Technical Issues Why Do Beacons Exist Beacons came about as a result of our desire to make it as easy as possible to get the Lighthouse ecosystem up and running We realized that many organizations may already have Docker swarms set up and it would be tedious to ad
15. e which may host Google Compute Engine Docker instances AWS A virtual machine hosting service by Amazon which may host Docker Amazon Web Service instances JSON A data exchange format which is the primary mode of communication JavaScript Object Notation between the frontend and backend applications A portion of the Lighthouse Project ecosystem It lives in the cloud and Beacon g E provides a single access point for Docker instances in the cloud The centralized backend of the Lighthouse Project ecosystem It Lighthouse provides an API to access all the Docker systems owned by an organization The front end web application built specifically for use with the Harbor SE Lighthouse Project It provides a responsive interface to Docker Table 1 Common terms and their definitions 2 DELIVERABLES The Lighthouse Project consists of the following modules Lighthouse The Lighthouse system is capable of interfacing with an existing instance of Docker It communicates with Docker instances via Docker s REST API and it is capable of e Routing all valid Docker API calls through itself to the appropriate Docker instance e Authenticating users using per instance permissions and blocking unauthorized requests e Extending Docker s functionality by intercepting requests to Docker and calling internal functions such as logging and history e Perform batch operations over a collection of Docker instances Harbor Harbo
16. es section above the single page application architecture with Harbor posed some interesting design challenges with regards to session management While we were able to build out a design around the architecture hindsight suggests a different approach should have been taken to ensure session management was central to the initial design process considering the multi user and collaborative nature of Lighthouse With that said there have been numerous benefits to our decision to use a single page architecture Client side template rendering is extremely responsive and increases the perception of speed as the user navigates through the application Strict client side data management means that other pages can be navigated to without transient data such as streaming updates having to persist in the slower browser cache or on the server Wrapping the entire front end into a unified framework also helped to ease the development process allowing us to effectively treat Harbor as a separate project in and of itself by placing it in a separate version control repository This means that Lighthouse and Harbor can have independent release cycles and two development branches can be tested simultaneously with minimal friction AngularJS and Go Coming into the initial development effort not everyone on our team had experience with the entire technology stack we had settled upon While this is certainly a common trend in professional development teams especiall
17. gure 7 Streaming concept diagram ssesssessssssseserirsrssesrsrrrrrnssssreerressssssrrernessssssrrerntssssenereennssssesereenessnt 12 Figure 8 Stream Processing code example oooocccccnccononooocncononnnononononnnnncnnnnnnonnnnnnnnnnnnnonornnnnnnnnnnnne nn nnnnnnnnnns 13 Figure 9 Deployment and Applicaiton database design ccccconocooooncnnnnonononannnncnnonananononnnnnnnncanononnnnnnnnnnnns 14 Figure 10 Streaming response general form ccccccononooonnnnncnnnnnononnnnonncnnnnnnonnnnnnnnnnnnnonnrnnnnnnnnnnnnennnnnnnnnnnns 15 Figure 11 Update Stream example iessen naea nanea a e E aa E e aae a ana ia eana a aieea DSe 16 Figure 12 Automated Testing checklet 18 RISACHER 20 Figure 14 Connecting to a BEACON erinadi deies aede ianari oee nn nono nn nono nono nono nono a sE a 21 Figure 15 First version with B aconss cccsessscccccecesseseaeceeecscesseaaaeeeeecssessesaeaecesecsssesesaeaeeeeeeesseseaaeaeesesens 23 28
18. he incoming streaming is processed Oboe s API model revolves around the knowledge of the stream structure as a JSON data segment to trigger state specific processing An example of this processing is given above for the application deploy stream Effectively oboe watches the incoming JSON stream for specific attributes in this case a specific key Status and calls the registered callback function for that event Harbor can then perform its own asynchronous data processing i e update the Ul to show the incremental deploy status Docker image pull streams are handled in a similar manner but instead a progress bar is updated during the callback Ultimately the consideration of streaming APIs and incremental status updates sets up an environment for more responsive Uls and a smoother user experience Streaming functionality can be further exploited to show real time network statistics and instance resource load Deployments and Applications Application management is one of Lighthouse s key features in terms of extending Docker s existing functionality When a developer thinks of their application they are probably imagining one object running in one location This abstraction works perfectly well for writing applications but a release manager does not have this luxury When a new version of an application is created the release manager has to think of the application as many objects running across many machines these machines
19. hey passed or failed Coveralls htips coveralls io helps us track code coverage for the test suite If the coverage decreases by a certain threshold around 6 a failure is indicated on the pull request This ensures that we meet a testing standard and that new code includes tests The following screenshot shows what that checklist looks like 17 A cmbrose lighthouse owners for your review Also completely open to ideas of how to do the drivers or any of this really in a cleaner way ngmiller 1 shing to the database flags branch on lighthouse lighthouse Y Allis well 3 successful checks Hide all checks Y continuous integration travis ci pr Details Y continuous integration travis ci push Details vi coveragelcoveralls Details This pull request can be automatically merged You can also merge branches on the command line k iaa Figure 12 Automated Testing checklist 6 CONCLUSION With the advent of Docker there has been a torrent of new technical challenges surrounding the technology Now that Docker has landed and has become an important and accepted industry standard the foundation has been created Some of the new challenges will be around building on top of this technology particularly management security and development of best practices Lighthouse s main purpose is to tackle the management of the Docker platform Our main goal is to make management of this platform simple efficient and secure B
20. mmunity surrounding Docker and isolated container based deployments grows so will the use cases for Lighthouse Even without considering the future changes to distributed application development the feature set of Lighthouse can certainly be increased in the meantime Two major features that come to mind are network monitoring for a specific container and resource monitoring for a Docker instance as whole Lighthouse and the related components Harbor and Beacon are licensed as open source under the Apache2 license allowing developers to contribute and expand on the project in the future 27 10 APPENDIX IV TABLE OF TABLES Table 1 Common terms and their deftnttions asken saiad siasii akasan kainak aeiia 4 Table 2 Key Valle Storage eege E E eeh Dee 24 Tables Schema Storag Ernion ee Eeer tad 24 11 APPENDIX V TABLE OF IMAGES Figure 1 System Block Diagramm 8 Figure 2 Harbor block diagram ccccccccccessssesssecececessesesseaecececesseseeeaeeeeecessuseaaeaeeeescesseseaaeaeeeescesseaaeaeesesens 9 Figure 3 An example of HarborisUl iin a aaia Aaa Aa Aaa ESANA Aa 9 Figure 4 Lighthouse block diagram cccsecsessscecececeesesesaececececessesaaaecececesessesaeaeseeecssseesaaaeeeeeceseeseaeaeeeeeens 10 Figure 5 Beacon block dagram seserinis reenen neeesa aei iene aeaee iaaiaee andens 10 Figure 6 Streaming Ulin Harbor ccccccccesssssssececeeecessesesaesececscesseseeseeeeeceseesesaeseeeeecsseeaaeaeeeeecesseseaaeaeeeeeens 11 Fi
21. ng a lot of coordination from Lighthouse and Beacon 5 TESTING The Lighthouse testing and code quality process consists of multiple steps that ensure a high quality product is being created while also allowing rapid development and continuous release We use a test driven development process to continuously deliver tested code throughout our development of Lighthouse This gives the project auditability and a solid set of standards Since we use Git and GitHub our development process revolves around pull requests These are requests to merge new code into the master branch of our repositories Once a developer has completed their task and is ready for it to be reviewed they create a pull request An example is here https github com lighthouse lighthouse pull 50 On this pull request developers can view the file additions and deletions discuss and review the code and ensure that certain checks have been met This methodology allows developers to review other s code and approve This leads to a very high quality product On each pull request a certain set of checks must be completed Our process requires the following for new code to be merged the full test suite must pass code coverage must not drop below a certain threshold and one of two other developers must sign off on it We use two services to assist with this process We use Travis Cl htips travis ci org to run the full test suite on every commit and report to GitHub whether t
22. ng and running the virtual machine and instead utilizes the native system resources while maintaining the desired isolation one would like to see between multiple applications running on one system Docker has achieved near native performance on application startup and shutdown meaning new applications can be deployed and scaled as quickly as possible Project Goals Our goal with Lighthouse is to provide a Docker host management system capable of interfacing with a variety of cloud providers including but not limited to Google Compute Engine and Amazon Web Services Lighthouse will allow users to authenticate with their target Docker host platform monitor the state of their application instances and deploy new containers from one centralized interface significantly reducing the time it requires to deploy and monitor applications across multiple cloud providers By the project completion our goal is to have built a system that is efficient modular and secure Definitions of Common Terms and Abbreviations Term Definition poder An open source platform used for creating packaging and shipping me and running applications REA A read only file system used by Docker which contains applications and other files i A running image which is writeable Containers are primarily used to Container SE KEEN run the applications that are being developed Registry An image storage service GCE A virtual machine VM hosting service by Googl
23. r any client expecting either a streaming response or blocking response A blocking client will not process its response until all incoming bytes have been stored and the connection closed In this case the underlying transport layer i e TCP seamlessly manages the incoming buffer passing it to the application layer i e client once the response is complete Therefore 12 all Docker responses from instances are treated as if they were streams since clients gracefully handle either case Lighthouse s second approach is focused on the application API Here incremental status objects as described the Applications section are written to the response stream and flushed immediately The end result here is the same as in Docker responses Harbor Harbor s internal services handle asynchronous requests and responses by utilizing the underlying browser API Asynchronous HTTP requests commonly referred to as Ajax have been prevalent for quite some time and many Javascript libraries take advantage of this providing a clean interface to develop against oboe method POST url _url request body request body start function process stream start node Status function status process status object fail function error process failure Figure 8 Stream Processing code example In Harbor s case it utilizes oboe js to process and dispatch internal events as t
24. r is a web application capable of utilizing Lighthouse to manage Docker instances It uses JavaScript AngularJS and Oboe to e Perform basic container management actions such as Create Stop Remove Update and Pause e View past containers run in the Docker instance That is view a history of each application running on the instance e Login and out of the backend application to authenticate frontend users e Stream the progress of batch operations to the user Beacon The beacon module resides within the cloud provider s network This gives it unique access to the provider s network internal APIs for discovering other servers being rented by the user The beacon module can e Detect what provider network it is running on in order to select the correct API e Detect Docker instances owned by the user and running within the same network e Redirect requests from the Lighthouse central back end to the relevant Docker instance The beacon module also includes its own API so support for new cloud providers can be added with ease Documentation The Lighthouse API is well documented in order to accommodate users that wish to automate actions create their own frontend applications or extend Harbor with new functionality This documentation can be found on GitHub under the Lighthouse organization 3 SYSTEM LEVEL DESIGN System Requirements Use Cases For a successful implementation of our minimal viable product we ve identified two major
25. s fields as a column This method was incredibly powerful as we could store and lookup any of our objects by any of its values The tables below shows how the actual storage inside the database changed using our table of Docker instances as an example 127 0 0 1 v1 12 InstanceAddress 127 0 0 1 v1 12 BeaconAddress 127 0 0 1 5001 Name mylnstance CanAccessDocker true Table 2 Key Value Storage InstanceAddress BeaconAddress Name CanAccessDocker Table 3 Schema Storage Obviously this method is clearer and has a much smaller storage overhead Its implementation is substantially more complicated but the benefits far outweigh this complexity and through unit testing we are confident that the implementation is correct The final paradigm shift in databases was due to a desire to add support for new databases Currently Lighthouse only supports Postgres databases but this is far less strict now than at it was at conception At some point the digital rubber must meet the road and real queries and execs must be generated Originally this was done inside the databases package itself and the package created strings specific to the Postgres syntax If the user s database did not support this syntax then Lighthouse was simply not going to work with it Of course this isn t a behavior most users would appreciate we needed a way to 24 be able to generate database specific strings
26. this proposal Application Management The concept of Applications is not implemented by Docker and as a result their design was one of the most complicated aspects of the project The initial concept was intercepting Container management requests that passed through Lighthouse and to group them by name into Applications With this method the frontend system would be largely in charge of performing the batch functionality required of Applications Ata high level this works but when the development process is considered there are issues the most obvious of which being that Applications are only loosely connected as Containers that share aname Consider developers who use Docker and create many containers for their own local tests It is very possible that these developers would be giving their containers names and we would very likely see Applications being created that weren t true Applications because of name collisions When we realized this the Applications infrastructure was modified to the stand alone architecture that it is now 25 9 APPENDIX lll OTHER CONSIDERATIONS The development process over the course of our project certainly proved to be challenging Early design choices forced us into certain conceptual models that played a large role in later work and learning new frameworks and languages in the process only added to the complexity of the work involved Single Page Application Architecture As outlined in the Technical Issu
27. to run on two cloud providers out of the box Those two cloud providers include Google Compute Engine and Digital Ocean Refer to the GitHub project read me for setting up Google Compute Engine and Digital Ocean for Beacon Otherwise Beacon offers the option of allowing a configuration file to define which VMs are available in a network For information on Beacon configuration files read this e Pull Image o docker pull lighthouse beacon latest e Basic Run o docker run d p 5000 5000 lighthouse beacon latest h 0 0 0 0 5000 e Using SSL o docker run d p 5000 5000 v path to cert dir certs lighthouse beacon latest key certs server key pem certs server pem h 0 0 0 0 5000 e Force Driver o docker run d p 5000 5000 lighthouse beacon latest driver config h 0 0 0 0 5000 e Use Custom Authentication Token 21 o Docker run d p 5000 5000 lighthouse beacon latest token imasecret h 0 0 0 0 5000 Setup Lighthouse e Pull Image o docker pull lighthouse lighthouse latest o docker pull postgres latest e Start Database o docker run name postgres image d postgres latest e Basic Run o docker run t i rm p 5000 5000 link postgres image postgres lighthouse lighthouse latest e Load Credentials Into Database From Config File o docker run t i rm p 5000 5000 link postgres image postgres lighthouse lighthouse latest databases reload 22 8 APPENDIX Il PREVIOUS VERSIONS During development the design of Lighthouse was constantl
28. tream logs OK Currently deployed applications testapp ID 1 admin gmail com deployed with ID 9 Deployment ID 5 5 hours ago Running ubuntu latest gt START STOP CREVERT Show recent deployments UPDATE Figure 6 Streaming UI in Harbor Lighthouse and Beacon To successfully build out a stream oriented API our design required coordination between each major component Lighthouse acting as the core mediator between each component in a request takes two approaches to handling response streams The first is focused on Docker requests 11 Incoming Docker requests are routed to the appropriate Beacon instance which in turn forwards the request onto the targeted Docker instance The open TCP connections are read from and written to in pre defined byte segments instead of the entire response The diagram below illustrates the connection relationship and read write characteristics Docker instance read queue TCP stream of byte segments read queue response request stream Y Client Figure 7 Streaming concept diagram The implementation for the read write portion of a component in the stack above is relatively straightforward A pre defined byte segment is read from the response buffer and relayed to the next client as a byte segment of the same size See Appendix IV One important aspect to consider is the nature of the listening client A nice property of this implementation is that it will work fo
29. use will handle the rest Reverting an Application Unfortunately mistakes are a very real event and when a bug in the code is bringing an application down it needs to be corrected as quickly as possible Lighthouse can be instructed to rollback applications any number of stages all the way back to the original version This makes the rollback process painless as the user can go back to a stable version without even having to enter a command Design and Implementation Database Design Applications are stored in two tables one storing the applications themselves and another which contains the different versions of the application which we call deployments Applications Deployments Id Int64 gt lt si Int64 CurrentDeployment Int64 Appld Int64 Name String Command JSON Instances String Creator String Date Date Figure 9 Deployment and Application database design 14 This design allows us to quickly get general information about an application by simply querying the Applications table and lets us perform new deployments by appending a new row to the Deployments table with the new command Batch Processing The key feature of application management is sending requests to many instances all at once we do this through batch processing For Lighthouse a batch process needs only a list of instances to communicate with and the message it needs to tell them From here the batch process will send requests to each instance in parallel
30. which will make the entire process much faster To keep the user informed the process will create an update stream which is used to report successes failures and any administrative data the user would need to know If any errors were to occur during the process a rollback procedure is performed to ensure that all instances are always in the same state as one another There are certainly cases where a single request from the user will need to send multiple requests to each instance an application update for example When multiple requests are needed each request waits for the one before it to complete before starting Concurrent request processing is easy to implement by using Go s goroutine and channel functionalities Channels operate as thread safe queues and goroutines are easy to make threads which each carry out one request to a single instance The goroutines carry out their function and then report their status to the master thread via channels The master thread simply spawns the thread and waits for them to end Streaming Responses For all of Lighthouse s application management functions which require batch operations the response to the client is in the form of a stream which is constantly updated The reason for this is to provide the client with real time updates of what is happening server side rather than having to wait for all processing to complete which could take several minutes before reporting anything These updates have
31. y communicating frequently with potential stakeholders making the project open and using standard and modern technologies we will be able to accomplish the goals outlined in this document which will allow Lighthouse to be a successful and useful tool for Docker management 18 Final Document v1 CprE 492 May15 17 7 APPENDIX I USER MANUAL Local Development Software Requirements The following items are required for building and running in a development environment Make sure this software is installed on your hardware before you do anything else e Docker note install boot2docker for OSX and windows operating systems e Node e Go e Git Pulling the Source Once you have the software installed it s time to clone the source code e Harbor git clone git github com lighthouse harbor git e Lighthouse go get t github com lighthouse lighthouse e Beacon go get t github com lighthouse beacon Installing Dependencies As soon as you ve pulled everything it s time to install the project dependencies e Harbor o npm install g bower o bower install o npm install g gulp o npm install g karma cli o npm install e Lighthouse o docker pull postgres latest Building Now that dependencies are installed it s time to build each project e Harbor o gulp build gopath e Lighthouse o go install github com lighthouse lighthouse e Beacon o go install github com lighthouse beacon Running Once we ve compiled everything it s
32. y reevaluated as we gained a better and better grasp of the problem domain There were very few modifications that would be noticed at a high level view the most prominent being the addition of Beacons Instead most design changes were hidden inside the lower parts of the technology stack examples of this being database paradigms Beacon implementations and Application management Addition of Beacons Early in design we intended for there to be only one end to end backend system which would have all the functionality now provided by Lighthouse as well as the abstractions provided by Beacon This would be achieved by having the provider drivers intercept outgoing requests which applied to the systems they managed and applying any additional headers or formatting that was required to access that system The figure below illustrates this early vision of Lighthouse This model was updated to the current version for two primary reasons The first was simply that the interception management would have added a lot of complexity to Lighthouse s pipeline The second and more important reason was that this model was not completely feasible as many cloud providers will have firewalls which would have blocked the requests coming from Lighthouse By installing Beacons inside the provider itself we allow Lighthouse to bypass this firewall in a secure manner Host Host Host Provider Provider Provider Provider Interface Provider Interface Provider Interface M
33. y with new hires it s important to take these factors into consideration when ramping up the development momentum The relative immaturity of AngularJS and Go meant certain issues were met too late in the development process and reverting the choice to use the framework and or language was not an option Fortunately the online communities surrounding these technologies are quite large and provided us with a platform and learning and troubleshooting not many environments have Requirements Gathering One of the major takeaways from our development process was considering the importance of the initial requirements gathering process Complexity in software is generally considered a rule not an exception with the end goal being to minimize both domain modeling complexity and accidental complexity in the feature set Initial meetings with our client Workiva were beneficial in providing us with a small set of initial features to begin developing but ultimately the direction of the project was left to our discretion While the freedom to develop an open ended project has its benefits there is a certain amount of benefit to restriction as well Small isolated software components allow for modular integration into larger systems and tend to be more stable pieces of software The work we ve done on Lighthouse has only solidified the understanding of a need for a rigid and comprehensive requirements gathering process 26 Future Work As the co
Download Pdf Manuals
Related Search