• English
Government of Canada

Search

Minutes for 2018-03-22

Minutes taken by: Zachary Seguin

Introduction

Canadian Digital Services - Collaboration Room

  • Canadian Digital Services / Statistics Canada organized
  • Importance of Cloud native
  • As Developers our view points aren’t always appreciated
  • Policy makers make decisions and we enact it

Vision

  • Long road, not everything can be done by cloud native
  • IaaS formulas, Amazon, Azure, etc. is not cloud native
  • Should focus on purely cloud native, can go any cloud
  • If it’s been solved in cloud native, we should take and learn. Share with everyone
  • Strive for developer freedom
  • Need to act as one voice
  • Group - skunkworks
  • Worried about procurement works in government
    • Azure service fabric (probably more .NET, weaker on non-.NET)
    • Pivotal
    • OpenShift
  • 1hr for planning items
  • Demo @ Statistics Canada

Planning Items

Departments

  • Public works
  • Canadian Digital Service,
  • TBS (Infobase, GC tools [containers, k8s, etc. - wiki fully in containers],
  • Open Government Portal [on azure]),
  • PSC [w/ SSC for OpenShift],
  • Statistics Canada,
  • ESDC [mobile app dev shop, purchasing public cloud for dev environments]

Scope

Ignore standard IaaS, cloud-specific technology.

  • Maybe how it maps into cloud-agnostic technology

Hybrid cloud - solutions should work on Amazon, Azure, OpenStack, Bluemix, etc. [on and off prems]

  • What about Compute Canada? [should be the same on on-premises]

Follow Canada’s Open First White paper

  • i.e., Open Source

Code of Conduct: CNCF Code of Conduct

  • Respect everyone
  • Guidelines to adhere to
  • Is there a government-specific one?
  • Values and ethics guideline probably covers it

Govcloud GitHub - skunkworks

  • Share stuff
  • Anyone wants to share, would be nice to share in one area

govcloud.ca - hosted Hugo static site

  • would like to see blog stuff sharing what we are working on
  • promote single developer who’s working in a department, make it more visible
  • acknowledge and share work

YouTube videos

  • Would be nice to go back and see what was demoed

Would be nice to host some of the foundational containers - GC Tools

  • Share base layers
  • Pull and extend, etc.
  • Centralized place for all of government to use

[Definition.]

Uses an open-source software stack:

  • containerized
  • dynamically orchestrated
  • microservices orientated

Methods of Communication

Preferences?

Will suggests Slack channel.

Some departments have blocked Slack.

  • What about GC Message? It’s a Rocket chat. message.gccloud.ca (happens to be running in a container)

Virtual Meetups

Some people asked for full virtual.

Hangouts is blocked at some departments.

WebEx should be accessible, but some departments have network issues.

  • At least one has a preference for in-room, not lag, etc.
  • Maybe for smaller ones
  • Play by ear.
  • Would allow outside of NCR
  • Fully remote is better than half-half

Subsequent Presentations

Would others be interested in sharing?

Yes there are some interested.

Other topics we can have if no one to present at a meeting (solve a problem, Stats will demo, etc.)

Really want others to share what they are working on.

Miscellaneous

Anything else?

  • There is also a GC Cloud working group (currently more enterprise architecture)
    • Does IaaS, container architecture, etc.
    • May dictate what developers use
    • Members from this group in that group may present both ways (to GCWG and to us)
  • Leave ourselves some breathing room for future when coming up with policies, guidelines, etc.
    • If they don’t work, we can make them better
  • Vendor participation?
    • Closed off to non-GoC at the moment
    • Vendors are NOT allowed, but we are interested in inviting them in
    • No objections
    • Make them aware to share expertise and NOT sell (NO SALES)
      • Pivotal and OpenShift want to show off what they have [we told them to wait a few meetings]
  • Get the word out to other developers (share the Meetup on Meetup.com)
  • Maybe sometimes have some social meetups after the meetings

Containers

  • Power on development and deployment side
  • Platform independence (local desktop, dev servers, prod servers, etc.)
  • Containers usually a few dozen MBs, some are larger (can do both)
  • Higher utilization of underlying hardware
  • Isolation from other containers
  • Used by Google and Twitter for years
  • 71% of Fortune 100 companies are running containers.

Didn’t mention Docker, but it’s one of many. Containerization should be more general.

  • Docker for Mac comes with Kubernetes
  • Swarm is still there, but may be gone in a few years

[Demo: github.com/drupalwxt/site-wxt]

[Demo: https://github.com/govcloud/docker-sas4c]

  • ADD/COPY will still be there if you use it, so adds to space use
  • Has a custom entry point script

Design Patterns

From: RedHat Design Principles

  1. Single concern: Every container should address a single concern and do it well (can also replace with a similar container)

  2. Image immutability: Regardless where the container is, it’s the same

  3. High observability: Unified way to package and run applications (as a black box), exposes APIs for reaching in (health check, liveness, readiness, logs, etc.)

  4. Lifecycle conformance: Application has way to read events coming from the platform - it should conform and respond

  5. Process disposability: Kill container and it’s gone

  6. Self containment: Container should contain everything it needs at build time (libraries, language runtime, etc.). Exceptions are things such as configurations, which must be provided at runtime.

  7. Runtime confinement: You can limit the resources of the container

Structural Patterns

From: Design patterns for container-based distributed system (Google, Burns and Oppenheimer) Structure among containers. These containers do not run alone, they run at a higher unit (e.g., pod)

  1. Sidecar: extends and enhances the functionality of an existing container with extending or modifying it

  2. Initializers: Separation of concerns by providing a separate lifecycle for initialization. All initializers have to finish in order and successfully for the application container to run.

  3. Ambassador: Specialized sidecar for hiding the complexity and provide a unified interface for external interfaces

  4. Adaptor: Abstracts some logic (e.g., make generic some external information)

Kubernetes

Network Tips

ClusterIP: Exposes the service on a cluster-internal IP. Only reachable within the cluster

NodePort: Most primitive way to get external traffic, all traffic to port on node will forward to the service

LoadBalancer: Exposes the service to the internet, all traffic will forward to the service

Ingress: Acts as a smart router for multiple services

Why?

  • Orchestrators organize containers across multiple nodes (each of which is equal)
  • Kubernetes has won the war among orchestrators. All public clouds have support for it, and most if not all provide a managed kubernetes service. PaaS are also adding support for it.
  • 2nd largest project on GitHub, > 30000 users on Slack (incl. Google engineers)

Demos

  • Kubernetes dashboard
  • Configmaps are output as files in the container
  • Draft (you have code but no helm chart / kubernetes manifests)
  • Helm (think of as a package manager)
  • Helm subcharting
  • VS Code / Helm + Kubernetes integration (regular Visual Studio does include it)
  • CNCF et al (Prometheus)
  • Azure AKS, ACS and ACS engine (https://github.com/Azure/acs-engine) (not enough time)
  • Pachyderm (not enough time)
Date modified: