Minutes taken by: Zachary Seguin
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
- 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)
- 1hr for planning items
- Demo @ Statistics Canada
- 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]
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
- 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
Uses an open-source software stack:
- dynamically orchestrated
- microservices orientated
Methods of Communication
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)
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
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.
- 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
- 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
- Auto builds on docker hub (https://hub.docker.com/u/drupalwxt/site-wxt/) when pushing to the repo
- Azure container registry available by request in Canada, available in US East
- ADD/COPY will still be there if you use it, so adds to space use
- Has a custom entry point script
From: RedHat Design Principles
Single concern: Every container should address a single concern and do it well (can also replace with a similar container)
Image immutability: Regardless where the container is, it’s the same
High observability: Unified way to package and run applications (as a black box), exposes APIs for reaching in (health check, liveness, readiness, logs, etc.)
Lifecycle conformance: Application has way to read events coming from the platform - it should conform and respond
Process disposability: Kill container and it’s gone
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.
Runtime confinement: You can limit the resources of the container
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)
Sidecar: extends and enhances the functionality of an existing container with extending or modifying it
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.
Ambassador: Specialized sidecar for hiding the complexity and provide a unified interface for external interfaces
Adaptor: Abstracts some logic (e.g., make generic some external information)
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
- 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)
- 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)