Code Monkey home page Code Monkey logo

projectcalico / calico Goto Github PK

View Code? Open in Web Editor NEW
5.5K 122.0 1.2K 160.89 MB

Cloud native networking and network security

Home Page: https://docs.tigera.io/calico/latest/about/

License: Apache License 2.0

Shell 2.23% Makefile 1.52% Python 7.15% Dockerfile 0.14% Smarty 0.01% Go 75.84% PowerShell 0.66% Starlark 0.01% C 12.41% Awk 0.01% HCL 0.04%
cni cni-plugin ebpf k8s kubernetes kubernetes-networking kubernetes-windows network-policy networking security

calico's Introduction

Go Report Card ArtifactHub License GoPkg CII Best Practices

๐Ÿพ Welcome to Project Calico!

Project Calico is an open-source project with an active development and user community. Calico Open Source has grown to be the most widely adopted solution for container networking and security, powering 8M+ nodes daily across 166 countries.

๐ŸŒŸ Why use Calico?

  • Data Plane Choice: eBPF, standard Linux, Windows, and VPP โ€” versatility in network solutions.
  • Interoperability: Works across multiple distros, multiple clouds, bare metal, and VMs.
  • Optimized Performance: Engineered for high speed and low CPU usage, maximizing your cluster investments.
  • Scalable Architecture: Grows seamlessly with your Kubernetes clusters without sacrificing performance.
  • Advanced Security: Get granular access controls and WireGuard encryption.
  • Kubernetes Networking Policy Support: Continually defining excellence in Kubernetes network policy standards and support.
  • Vibrant Contributor Community: Over 200 contributors from a wide array of global companies.
  • Flexible networking: An array of networking tools at your disposal, including BGP, VXLAN, service advertisement, and more.

๐Ÿค Join the Calico Community

๐Ÿ’ก Contributing to Project Calico

๐Ÿ› ๏ธ Projects We Maintain

๐Ÿ“ข Stay Connected

calico's People

Contributors

alexaltair avatar bcreane avatar bmckercher123 avatar brian-mcm avatar caseydavenport avatar coutinhop avatar djosborne avatar emanic avatar fasaxc avatar gunjan5 avatar heschlie avatar hjiawei avatar jsoref avatar kelseyhightower avatar lmm avatar lukasa avatar lwr20 avatar marvin-tigera avatar matthewdupre avatar mazdakn avatar mgleung avatar ozdanborne avatar robbrockbank avatar saumoh avatar song-jiang avatar sridhartigera avatar tmjd avatar tomastigera avatar tomdee avatar trimbiggs avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

calico's Issues

Add badges, or similar, to show what our supported platforms are

It would be great to have something a little flashy on the front page with badges highlighting our support platforms (e.g. OpenStack Mitaka, Kubernetes XXX). Not quite sure, though, how easy it will be to provide something concise (e.g. for OpenStack, technically we support icehouse, Kilo, Liberty and Mitaka).

Links to performance studies

There are a number of independent studies on container networking perf which feature Calico. Would be nice if we could collect those in one place so they are easy to find, as per a user request on Slack.

Document use of link-local address as gateway

From @caseydavenport on June 17, 2016 16:20

We set up the following routes within a container to get traffic out to the host:

default via 169.254.1.1 dev eth0
168.254.1.1 dev eth0

We should document this so that it isn't confusing / surprising to users.

Copied from original issue: projectcalico/calico-containers#1023

Datamodel documentation shouldn't be tied to etcd

Currently, it goes into detail about how the data is stored in etcd.

The docs should discuss the higher-level "libcalico" concepts. There can still be a doc which discusses the specifics of the etcdv2 / etcdv3 / etc implementations, but it should be separate (either as separate docs on the site, or as markdown files in the libcalico repo (since it is highly technical).

Black-hole traffic to unknown IP pool addresses

TL;DR: sent packet from Jenkins server to VM IP address that wasn't in compute node's routing table yet; packet got forwarded to default LAN gateway even though it was for an address in the IP pool. Should we black-hole such traffic instead?

We hit this in the test rig; I'm not 100% sure if it's relevant in a real deployment. We're using subnets of 10/8 for our various network IP pools and we have our jenkins test server set up with a static route for all of 10/8 that goes to one of the compute nodes. Jenkins creates a network, and adds a VM into it then it tries to ssh into the VM.

There is a race where the ssh TCP packets get to the compute node before the route to the VM is in place and until the route is in place, the compute node seems to forward packets that were destined for the VM to its default gateway, which is on our internal LAN.

Since the internal LAN has some routes to (a different) 10/8 (I know, we're being naughty re-using addresses), our packets end up forwarded round the houses and come back (as dest unreachable) via a different route. I think that incorrect route then gets cached causing further problems (we were seeing Jenkins trying to send packets to the VM via the default gateway instead of via the compute node).

Docs should include intro slide diagram

From @matthewdupre on March 16, 2016 16:44

We should review the intro slide deck and put any useful diagrams into the docs: this should be pitched at someone about the level of "someone told me Calico was cool: what is it?".

Copied from original issue: projectcalico/felix#994

Visited links are hard to spot

A vlink colour that contrasts more with black would be nice.

Perhaps a bit lighter, although I'm not sure people would want it to be pink? WDYT?

robots.txt

We should investigate SEO with robots.txt

FAQ for common calico philosophy misunderstandings

I find there a lot of users in the slack channel who haven't fully grocked Calico philosophy, so they're ask narrow questions based on a larger misconception. I'm opening this issue to track a running list of these common questions:

Question: How do I choose which pool my task is assigned an IP from?
Often users are asking this question for the wrong reason. Different pools are only really necessary when choosing which routes to broadcast beyond the TOR. Pool selection should never be used to enforce policy.

Standardize information spread across sub-repos

Now that most of our documentation is located in one place, we should revisit each repository and ensure it has the correct documents in it. This means coming up with a plan for how we display (for example):

  • README.md
  • CONTRIBUTING.md
  • BUILDING.md

We should also which (shared) information should be placed in the new docs site

Improve Navbar Layout

The v1.5 navbar layout works well to fit our existing documentation into a new, tree-based site. Now that a 1:1 cut has been made, we should move forward with more drastic changes to our layout. This new layout should address the following issue(s) (feel free to comment with more, or open other issues to tackle smaller components of this greater epic):

  • Consider if cloud guides should become shared reference material explaining cloud-specific gotchas (AWS src/dest checking, Azure ipip, etc.)

Fix links to Juju bundles...

... when we reorg the docs, make sure the links to the Juju bundles (if we keep the section on Juju) are correct and include the bundles for Liberty/Mitaka.

`calicoctl endpoint remove` is documented but not implemented

From @xh3b4sd on September 29, 2016 14:28

As documented on how to stop a calico node it is advised to call calicoctl endpoint remove. This in fact results into the following.

core@xh3b4sd-k8svm-master ~ $ calicoctl endpoint remove
Usage:
  calicoctl endpoint show [--host=<HOSTNAME>] [--orchestrator=<ORCHESTRATOR_ID>]
    [--workload=<WORKLOAD_ID>] [--endpoint=<ENDPOINT_ID>] [--detailed]
  calicoctl endpoint <ENDPOINT_ID> profile (append|remove|set) [--host=<HOSTNAME>]
    [--orchestrator=<ORCHESTRATOR_ID>] [--workload=<WORKLOAD_ID>]  [<PROFILES>...]
  calicoctl endpoint <ENDPOINT_ID> profile show [--host=<HOSTNAME>]
    [--orchestrator=<ORCHESTRATOR_ID>] [--workload=<WORKLOAD_ID>]

I feel like I am doing something fundamentally wrong. Can somebody provide feedback here?

Copied from original issue: projectcalico/calico-containers#1176

Proposal: add links to repos in "Releases" tab

right now it only lists the repos with latest as version, it might be a good idea to add links to the repos in one place.

The page under References > Repo structure doesn't have it in a list format and isn't an obvious location a user would look, but Releases tab seems like a good place to have those links there

No IPAM documentation

From @caseydavenport on February 3, 2016 0:50

I can't find any documentation that describes Calico's IPAM behavior and how it interacts with pools. This would be useful info for Calico users to have.

Copied from original issue: projectcalico/calico-containers#784

Improve the "Introduction" Content

So that users who come to Calico understand the value proposition that Calico offers and the use-cases it tries to solve.

It is important that people who are new to Calico understand why someone would want to use it, as well as how it works. This probably serves twofold:

  • Make more people realize that they actually do want Calico to meet their use-case.
  • Filters out users for whom Calico is not actually a good fit for their use-case.

Note that this may be a global document and/or individual documents per-orchestrator, to advertise the features that Calico brings to each environment.

Configuration info is too scattered across docs

The configuration page currently talks about system and Felix configuration but it doesn't talk about calicoctl or how to set config values.

I think we should have a landing page that gives an overview of the different types of configuration we support and why you'd want to tweak each of them (System requirements; Felix; BGP; integration-specific) and fans people out to more detailed docs.

Work out how/where we're going to host the Calico docs

The format of the docs in the repo is such that they can be built/hosted by Github pages, if that's what we want.

As it stands, the docs in the gh-master branch of this repo are hosted on tigera.github.io/calico-docs, but we'll presumably want to put the docs in a projectcalico repo, which would move their default location (e.g. projectcalico.github.io/calico).

Github pages supports custom domains (https://help.github.com/articles/using-a-custom-domain-with-github-pages/), so it should be possible to actually have them hosted by github but located somewhere else (e.g. replace the current docs.projectcalico.org).

Basically, we should be able to do what we want - just needs someone to make a decision on what that is.

Improve Style Theme

The docs site could use improvements to its theme that accomplishes the following:

  • Adhere to html best practices (screen width, spacing, etc.)
  • Giv Calico a unique, appealing look
  • Easy to use properly

Change the colours of the social buttons

In the current branding, the social buttons are somewhat "kubernetes blue". We should change the /images/social-sprite.png to be more Calico Orange (#f69432).

The "Getting involved" documentation needs updating to point to calico-containers and other calico-container related repos

From @robbrockbank on February 8, 2016 19:23

The involved.rst document currently points at calico-docker.

  • The calico-docker repo has been renamed to calico-containers
  • There are a number of other calico-container related repos that we should also point to
  • calico-mesos
  • calico-kubernetes
  • calico-cni
  • libcalico
  • libnetwork-plugin

etc.

Copied from original issue: projectcalico/felix#976

Make calico-node friendly to read-only filesystems / runc containerization

As an improvement on running calico-node as a docker daemon (with the associated chicken-egg problem with calico-libnetwork), we've been looking at running it as a simple docker-runc service instead. This has the benefit of being easier to stream into a disk image on first provisioning, and running more natually as an init job rather then a docker job.

Unfortunately, the existing calico-node container is quite badly organized for this task, assuming that a large number of endpoints are writeable which probably shouldn't be.

As a first pass, this is a configuration (derived from the docker one) which works for me (with a read-only calico-node blob):

EDIT: Updated the calico blob with the one I'm using for calico-node 1.0.0beta.

{
  "hooks": {}, 
  "hostname": "runc", 
  "linux": {
    "maskedPaths": [
      "/proc/kcore", 
      "/proc/latency_stats", 
      "/proc/timer_stats", 
      "/proc/sched_debug"
    ], 
    "namespaces": [
      {
        "type": "pid"
      }, 
      {
        "type": "ipc"
      }, 
      {
        "type": "uts"
      }, 
      {
        "type": "mount"
      }
    ], 
    "readonlyPaths": [
      "/proc/asound", 
      "/proc/bus", 
      "/proc/fs", 
      "/proc/irq", 
      "/proc/sys/abi", 
      "/proc/sys/debug", 
      "/proc/sys/dev", 
      "/proc/sys/fs", 
      "/proc/sys/kernel", 
      "/proc/sys/vm", 
      "/proc/sysrq-trigger"
    ], 
    "resources": {
      "devices": [
        {
          "access": "rwm", 
          "allow": true
        }
      ]
    }
  }, 
  "mounts": [
    {
      "destination": "/proc", 
      "options": [
        "nosuid", 
        "noexec", 
        "nodev"
      ], 
      "source": "proc", 
      "type": "proc"
    }, 
    {
      "destination": "/dev", 
      "options": [
        "nosuid", 
        "strictatime", 
        "mode=755", 
        "size=65536k"
      ], 
      "source": "tmpfs", 
      "type": "tmpfs"
    }, 
    {
      "destination": "/dev/pts", 
      "options": [
        "nosuid", 
        "noexec", 
        "newinstance", 
        "ptmxmode=0666", 
        "mode=0620", 
        "gid=5"
      ], 
      "source": "devpts", 
      "type": "devpts"
    }, 
    {
      "destination": "/dev/shm", 
      "options": [
        "nosuid", 
        "noexec", 
        "nodev", 
        "mode=1777", 
        "size=65536k"
      ], 
      "source": "shm", 
      "type": "tmpfs"
    }, 
    {
      "destination": "/dev/mqueue", 
      "options": [
        "nosuid", 
        "noexec", 
        "nodev"
      ], 
      "source": "mqueue", 
      "type": "mqueue"
    }, 
    {
      "destination": "/sys", 
      "options": [
        "nosuid", 
        "noexec", 
        "nodev", 
        "ro"
      ], 
      "source": "sysfs", 
      "type": "sysfs"
    }, 
    {
      "destination": "/sys/fs/cgroup", 
      "options": [
        "nosuid", 
        "noexec", 
        "nodev", 
        "relatime", 
        "ro"
      ], 
      "source": "cgroup", 
      "type": "cgroup"
    }, 
    {
      "destination": "/lib/modules", 
      "options": [
        "rbind", 
        "rprivate"
      ], 
      "source": "/lib/modules", 
      "type": "bind"
    },
    {
      "destination": "/var/log/calico",
      "options": [
        "rbind",
        "rprivate"
      ],
      "source": "/var/log/calico",
      "type": "bind"
    },
    {
      "destination": "/var/run/calico", 
      "options": [
        "rbind", 
        "rprivate"
      ], 
      "source": "/var/run/calico", 
      "type": "bind"
    }, 
    {
      "destination": "/etc/resolv.conf", 
      "options": [
        "rbind", 
        "rprivate", 
        "ro"
      ], 
      "source": "/etc/resolv.conf", 
      "type": "bind"
    }, 
    {
      "destination": "/etc/hostname", 
      "options": [
        "rbind", 
        "rprivate", 
        "ro"
      ], 
      "source": "/etc/hostname", 
      "type": "bind"
    }, 
    {
      "destination": "/etc/hosts", 
      "options": [
        "rbind", 
        "rprivate", 
        "ro"
      ], 
      "source": "/etc/hosts", 
      "type": "bind"
    },
    {
      "destination": "/felix-startup-1.log", 
      "options": [
        "rbind", 
        "rprivate"
      ], 
      "source": "/var/run/calico/node/felix-startup-1.log", 
      "type": "bind"
    }, 
    {
      "destination": "/felix-startup-2.log", 
      "options": [
        "rbind", 
        "rprivate"
      ], 
      "source": "/var/run/calico/node/felix-startup-2.log", 
      "type": "bind"
    }, 
    {
      "destination": "/etc/envvars", 
      "options": [
        "rbind", 
        "rprivate"
      ], 
      "source": "/var/run/calico/node/envvars", 
      "type": "bind"
    }, 
    {
      "destination": "/startup.env", 
      "options": [
        "rbind", 
        "rprivate"
      ], 
      "source": "/var/run/calico/node/startup.env", 
      "type": "bind"
    },
    {
      "destination": "/etc/service/enabled", 
      "options": [
        "nodev"
      ], 
      "source": "tmpfs", 
      "type": "tmpfs"
    }, 
    {
      "destination": "/etc/calico/confd/conf.d", 
      "options": [
        "rbind", 
        "rprivate"
      ], 
      "source": "/var/run/calico/node/confd/conf.d", 
      "type": "bind"
    },
    {
      "destination": "/etc/calico/confd/config", 
      "options": [
        "noexec", 
        "nodev"
      ], 
      "source": "tmpfs", 
      "type": "tmpfs"
    }, 
    {
      "destination": "/run", 
      "options": [
        "noexec", 
        "nodev"
      ], 
      "source": "tmpfs", 
      "type": "tmpfs"
    }, 
    {
      "destination": "/tmp", 
      "options": [
        "nodev"
      ], 
      "source": "tmpfs", 
      "type": "tmpfs"
    },
    {
      "destination": "/run/docker/plugins", 
      "options": [
        "rbind", 
        "rprivate"
      ], 
      "source": "/run/docker/plugins", 
      "type": "bind"
    },
    {
      "destination": "/var/run/docker.sock", 
      "options": [
        "rbind", 
        "rprivate"
      ], 
      "source": "/var/run/docker.sock", 
      "type": "bind"
    }
  ], 
  "ociVersion": "0.6.0-dev", 
  "platform": {
    "arch": "amd64", 
    "os": "linux"
  }, 
  "process": {
    "args": [
      "/sbin/start_runit"
    ], 
    "capabilities": [
      "CAP_CHOWN", 
      "CAP_DAC_OVERRIDE", 
      "CAP_DAC_READ_SEARCH", 
      "CAP_FOWNER", 
      "CAP_FSETID", 
      "CAP_KILL", 
      "CAP_SETGID", 
      "CAP_SETUID", 
      "CAP_SETPCAP", 
      "CAP_LINUX_IMMUTABLE", 
      "CAP_NET_BIND_SERVICE", 
      "CAP_NET_BROADCAST", 
      "CAP_NET_ADMIN", 
      "CAP_NET_RAW", 
      "CAP_IPC_LOCK", 
      "CAP_IPC_OWNER", 
      "CAP_SYS_MODULE", 
      "CAP_SYS_RAWIO", 
      "CAP_SYS_CHROOT", 
      "CAP_SYS_PTRACE", 
      "CAP_SYS_PACCT", 
      "CAP_SYS_ADMIN", 
      "CAP_SYS_BOOT", 
      "CAP_SYS_NICE", 
      "CAP_SYS_RESOURCE", 
      "CAP_SYS_TIME", 
      "CAP_SYS_TTY_CONFIG", 
      "CAP_MKNOD", 
      "CAP_LEASE", 
      "CAP_AUDIT_WRITE", 
      "CAP_AUDIT_CONTROL", 
      "CAP_SETFCAP", 
      "CAP_MAC_OVERRIDE", 
      "CAP_MAC_ADMIN", 
      "CAP_SYSLOG", 
      "CAP_WAKE_ALARM", 
      "CAP_BLOCK_SUSPEND", 
      "CAP_AUDIT_READ"
    ], 
    "cwd": "/", 
    "env": [
      "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", 
      "HOSTNAME={{HOSTNAME}}", 
      "ETCD_ENDPOINTS={{ETCD_ENDPOINTS}}", 
      "ETCD_SCHEME={{ETCD_SCHEME}}", 
      "ETCD_CA_FILE={{ETCD_CA_FILE}}", 
      "ETCD_CERT_FILE={{ETCD_CERT_FILE}}", 
      "ETCD_KEY_FILE={{ETCD_KEY_FILE}}", 
      "CALICO_NETWORKING_BACKEND={{CALICO_NETWORKING_BACKEND}}",
      "CALICO_LIBNETWORK_ENABLED={{CALICO_LIBNETWORK_ENABLED}}",
      "NO_DEFAULT_POOLS={{NO_DEFAULT_POOLS}}", 
      "AS={{AS}}", 
      "IP={{IP}}", 
      "IP6={{IP6}}", 
      "DOCKER_API_VERSION=1.21"
    ], 
    "noNewPrivileges": true, 
    "rlimits": [
      {
        "hard": 1024, 
        "soft": 1024, 
        "type": "RLIMIT_NOFILE"
      }
    ], 
    "terminal": false, 
    "user": {}
  }, 
  "root": {
    "path": "/opt/calico-node", 
    "readonly": true
  }
}

You also generally need a unit file to launch this with (I'm using j2cli to do templating of the config.json):

[Unit]
Description=Calico Network Node
After=docker.service
Requires=docker.service
After=etcd.service

[Service]
# Source static environment for Calico
EnvironmentFile=/etc/calico/calico.env
Environment=HOSTNAME=%H
Environment=CALICO_NETWORKING_BACKEND=bird
Environment=CALICO_LIBNETWORK_ENABLED=true
Environment=NO_DEFAULT_POOLS=true
Environment=AS=
Environment=IP=
Environment=IP6=

# runc requires pre-mount paths exist.
ExecStartPre=/bin/mkdir -p /run/calico/node \
                           /run/calico/node/confd/conf.d \
                           /var/log/calico \
                           /run/docker/plugins

# deal with calico's/conf.d's desire to write and template in /etc
ExecStartPre=/bin/cp -r /opt/calico-node/etc/calico/confd/conf.d \
                        /run/calico/node/confd

ExecStartPre=/bin/touch /run/calico/node/envvars \
                        /run/calico/node/startup.env \
                        /run/calico/node/felix-startup-1.log \
                        /run/calico/node/felix-startup-2.log

# Template the container config file.
ExecStartPre=/bin/bash -c "/usr/local/bin/j2 -f env /opt/calico-node/config.json.j2 > /run/calico/node/config.json"
ExecStart=/usr/bin/docker-runc --systemd-cgroup start -b /run/calico/node calico-node

Restart=always
RestartSec=10s

[Install]
WantedBy=multi-user.target

Softcode the version selection dropdown

The versioned dropdown selector at the top-right is hardcoded in docwithnav.html. We should consider a cleaner approach to this.

Much of the versioned components of the site are done based on the variable set in _config.yml for the cwd. This method can't easily be applied to pieces of the site that point to other versions. We need a different method.

One suggestion is to add a yaml file to the toplevel _data which describes the available versions. Then docwithnav can render the dropdown based on the file.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.