infrastructure ◦ Public applications must be firewalled from Internal applications (HIPAA) • Rapid prototyping and demoing of applications ◦ Victims of our own success • Large infrastructure, small staff ◦ 40+ independant in house developed applications or services ◦ 1 Designer, 1.5 Developers, 1.5 Sysadmins
Source Control server notifies Build Server of new commit. Build Server schedules build at new commit. If build successful; tag image and push to registry. Otherwise notify group. After successful build pushed to the registry, trigger cluster update. Notify if problem arises during update. Build
Cluster determines hosts with appropriate resource offerings. Hosts pull containers associated with task. Once containers pass healthcheck, front end is notified of host:port Front End updates configuration and reloads with new services. Service is now accessible to public network
(GitHub) • Low barrier to entry for non-developers • Existing integration into other “pillars” (Jenkins) • Now comes in a handy dandy container ◦ “ docker pull gitlab/gitlab-ce ” ◦ https://hub.docker.com/r/gitlab/gitlab-ce/
◦ LDAP backed. ◦ RBAC - v0 api available, use and integration capability growing. ▪ https://docs.docker.com/docker-trusted-registry/api/ ◦ One-click upgrade. ◦ User friendly UI. • Support Offerings ◦ 24/7 support REQUIRED for use in a clinical care setting. ◦ Guided install with staff on-site where needed
host systems (both physical and virtual). • Caters well to an on prem solution. • Slightly more mature in the cluster solution ecosystem. ◦ Powered by Mesos Users - http://mesos.apache.org/documentation/latest/powered-by-mesos/ • Large framework ecosystem; with lots of active development.
support is REQUIRED when used in a clinical setting. • Certified stable releases suitable for production use. • Predictable release schedule for upgrade planning. • Orchestration components are swappable...docker engine is not, and is the base requirement for everything.
should be independent of infrastructure design. ◦ Container init script + environment or cluster seed script. ▪ container init script variables are static ▪ seed script populates container init script with cluster specific information. ▪ Build server can inject seed script for environment (local dev vs cluster deployment)
container creation or ‘seeded’ via a script sourced as $ENVIRONMENT_INIT . The supplied script could hit a variety of endpoints for configuration information (consul, etcd, registrator, etc). If nothing is provided, it assumes the default value. This allows for init script to remain static, with only the sourced seed script changing per environment.
may modify host configuration require some level of clean-up. e.g. anything that may require iptables. ◦ trap SIGINT, SIGKILL etc. then perform action. ◦ Does require some form of ‘init’ or process management. - supervisord, tini, monit etc • Use of VRRP / Keepalived and deploying in pairs when services may be bound to a single point of failure (no DNS load balancing etc). ◦ Provides incredibly simple IP failover. ◦ Prerequisites for use: ▪ sysctl - net.ipv4.ip_nonlocal_bind=1 ▪ container run with host networking and cap NET_ADMIN ◦ Added bonus of making it EXTREMELY easy to upgrade and switch services. ▪ If upgrading: push new version to backup, then push to master.
or BACKUP - Defines server role in the group. • interface - The interface that keepalived will use for VRRP traffic and monitor by default. • vrrp_unicast_bind - The ip in which vrrp should bind to. • vrrp_unicast_peer - The bind ip of the other node in the group. • virtual_router_id - Unique number between 1-255 that identifies the vrrp group. Multiple instances of vrrp can run at the same time on the same servers. • priority - In scenarios with more than 2 nodes, priority will dictate the failover order with highest priority becoming the master. • advert_int - Healthcheck interval (seconds) • authentication - PASS (cleartext password) or AH (IPSEC Authorization Header). Password and method used by the nodes to validate each other. • virtual_ipaddress - Virtual IP Address to be generated and interface it should be bound to. IPs in this block WILL be tracked by keepalived. Used for private network interface tracking. • virtual_ipaddress_excluded - Virtual IP Address to be generated and interface it should be bound to. IPs in this block will NOT be tracked, but automatically failed over if an event would trigger a failure of IP(s) in the virtual_ipaddress block. Used for public facing IPs. • track_interface - Interface adapters that should have their link state monitored for failover trigger.