kumahq / kuma-website Goto Github PK
View Code? Open in Web Editor NEWπ» The official website for Kuma, the control plane for modern service connectivity.
Home Page: https://kuma.io
License: Apache License 2.0
π» The official website for Kuma, the control plane for modern service connectivity.
Home Page: https://kuma.io
License: Apache License 2.0
service.kuma.io/protocol
annotationToday we show all the versions, like:
0.7.0
, 0.7.1
, 0.8.0
, 0.8.1
Change this so that we show only the latest minor for each major release, like:
0.7.x
, 0.8.x
docker run -ti -p 8080:8080 -v ${PWD}:/source circleci/node bash
yarn docs:dev
inside it, I can't access http://localhost:8080
from the host (apparently, dev server is started on 127.0.0.1:8080
instead of 0.0.0.0:8080
, which makes it inaccessible through standard docker run -p 8080:8080
)The header says:
https://kuma.io/docs/0.5.0/policies/traffic-trace/#add-a-tracking-backend
But all the other references to what is being added refer to it as "tracing backend" which is confusing.
4. Done!
of Ubuntu installation page (https://kuma.io/docs/0.2.2/installation/ubuntu/)Take the example YAML from https://kuma.io/docs/1.2.3/policies/traffic-route/#usage and apply it with kumactl
:
jpeach@greenling:~/upstream/konghq/kuma$ kumactl apply -f /tmp/t
Error: YAML contains invalid resource: error converting YAML to JSON: yaml: line 30: found unknown escape character
jpeach@greenling:~/upstream/konghq/kuma$ kumactl apply -f /tmp/t
Error: YAML contains invalid resource: error converting YAML to JSON: yaml: line 35: found unknown escape character
The problem is escapes pattern substitutions like "\2/instance/\1"
. Because of the double-quote, the YAML parser tries (and fails) to interpret this as an escape. This should be using single quotes.
People not familiar with Grafana would take a while to figure what to do to search their loki traffic logs.
We should explain what to do.
With each version release of Kuma, the Helm install instructions should specify that is the version being installed. With any Helm install documentation version you are always getting the latest version of Kuma.
From:
$ helm install --create-namespace --namespace kuma-system kuma kuma/kuma
To:
$ helm install --version x.y.z --create-namespace --namespace kuma-system kuma kuma/kuma
The helm install
command specifies the version of the chart, not the version of Kuma, so that needs to be taken into consideration for each version release.
Until we refactor Dataplane of type Ingress to cluster-scoped ZoneIngress. It would be great to mention somewhere that you have to have 1 Ingress per zone, not per mesh
Resources HTTP API should have kuma.io/
prefix in tags
We should make clear to the users that mesh
is a higher-level concept than namespace
. Meaning - you can have one mesh across multiple namespaces.
Also add a note that when Kuma applies policies, it fetches them from all the namespaces.
The entire page is now only partly copyedited. Needs a full rework and thorough technical review for all the bits that haven't been touched in a long time.
Originally posted by @bdecoste in kumahq/kuma#1948
Links to Listeners, Clusters, etc are broken here: https://kuma.io/docs/1.1.4/policies/proxy-template/
$ yarn install
yarn install v1.17.3
[1/4] π Resolving packages...
[2/4] π Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/@kongponents/kbutton/-/kbutton-0.0.1-beta.6.tgz: Request failed \"404 Not Found\"".
info If you think this is a bug, please open a bug report with the information provided in "/Users/marco/git/konvoy-website/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
hi, I'm trying to use kuma-demo with universal mode following to https://kuma.io/docs/0.7.2/quickstart/universal/ .
I did step by step "1. Run the Marketplace application" -> "2. Enable Mutual TLS and Traffic Permissions" -> "3. Visualize Traffic Metrics" but when I try to see Grafana dashboard at http://192.168.33.80:3000 , Grafana dashboard itself is shown, but there is no metrics data. And also when I checked Prometheus dashboard at http://192.168.33.80:9090/targets , all targets are down with error message "read: connection reset by peer".
Then, I applied below Traffic Metric Policy following to https://github.com/kumahq/kuma-demo/blob/master/vagrant/README.md#traffic-metrics , Ican see metric data at Grafana dashboard.
$ cat <<EOF | kumactl apply -f -
type: Mesh
name: default
mtls:
enabledBackend: ca-1
backends:
- name: ca-1
type: builtin
metrics:
enabledBackend: prometheus-1
backends:
- name: prometheus-1
type: prometheus
conf:
skipMTLS: true
EOF
So, I think this doc https://kuma.io/docs/0.7.2/quickstart/universal/ causes misunderstanding. IMO it's better to replace with above manifest in "3. Visualize Traffic Metrics". How do you think?
My enviroment:
Originally posted by @bdecoste in kumahq/kuma#1810
The link at used to generate Dataplane Token is bad: https://kuma.io/docs/1.1.2/documentation/cli/#kumactl
Something has gone wrong on the tracing example https://kuma.io/docs/1.2.3/policies/traffic-trace/#add-jaeger-backend. Note that the Universal tab contains both Kubernetes and Universal YAML blocks
wget downloads.kuma.io/0.1.2/kuma-0.1.2-ubuntu.tar.gz
wget
fails with an error--2019-09-13 11:00:47-- http://downloads.kuma.io/0.1.2/kuma-0.1.2-ubuntu.tar.gz
Resolving downloads.kuma.io (downloads.kuma.io)... failed: nodename nor servname provided, or not known.
wget: unable to resolve host address <<downloads.kuma.io
You can download Kuma from here
linkhttps://kong.bintray.com/kuma/:kuma-0.1.2-debian.tar.gz
is opened in a new tabThere are image differences between v0.4.0 and v0.5.0.
So some image links are broken in v0.5.0 docs as below:
https://github.com/Kong/kuma-website/search?q=diagram-02.jpg+OR+diagram-03.jpg+OR+diagram-06.jpg+OR+diagram-07.jpg+OR+diagram-10.jpg+OR+diagram-11.jpg+path%3A%2Fdocs%2Fdocs%2F0.5.0&unscoped_q=diagram-02.jpg+OR+diagram-03.jpg+OR+diagram-06.jpg+OR+diagram-07.jpg+OR+diagram-10.jpg+OR+diagram-11.jpg+path%3A%2Fdocs%2Fdocs%2F0.5.0
It would be good to fix this for kuma users.
This issue is pending resolution of this issue: kumahq/kuma#2689
Once this issue is resolved and "proper" locality-aware load balancing functionality has been implemented, we need to update the documentation for locality-aware load balancing.
This issue covers improving the explanation for the current implementation. Docs will be updated when the above issue is completed.
The Kuma community page at https://kuma.io/community/ lets you subscribe to the the calendar (I guess that's what the email does?), but it would also be really useful if there was a link to the notes from the calls and the recordings of those calls.
Kuma has better out-of-the-box metrics for investigating traffic than Istio, but it is difficult to understand what metrics are actually exposed by looking at Kuma's Metrics page. It would be nice to do something like Istio's Standard Metrics, where some key metrics are listed and briefly explained.
The current traffic permission docs for kubernetes just use service name to match which is incorrect. Need to update docs since on kuberenetes the service name changes to something like redis-master.kuma-demo.svc:6379
There is pretty good explanatory documentation describing what a Dataplane
resource is and how it fits into the Kuma resource model, but I wasn't able to find an reference documentation. It would be helpful to have reference material describing all the available fields in this resource.
Originally posted by @bdecoste in kumahq/kuma#1949
Doc here is now outdated and broken. Latest envoy does not support v2: https://kuma.io/docs/1.1.4/policies/proxy-template/#examples
'@type': type.googleapis.com/envoy.config.filter.http.lua.v2.Lua
needs to be
'@type': type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
Also, the inline_code is also broken:
[2021-05-05 16:23:17.043][16353][info][lua] [source/extensions/filters/http/lua/lua_filter.cc:175] envoy_on_response() function not found. Lua filter will not hook responses
[2021-05-05 16:18:40.952][16353][warning][misc] [source/common/protobuf/utility.cc:294] Configuration does not parse cleanly as v3. v2 configuration is deprecated and will be removed from Envoy at the start of Q1 2021: envoy.config.filter.http.lua.v2.Lua
[2021-05-05 16:18:40.965][16353][warning][config] [source/common/config/grpc_subscription_impl.cc:107] gRPC config for type.googleapis.com/envoy.config.listener.v3.Listener rejected: Error adding/updating listener(s) outbound:240.0.0.0:80: The v2 xDS major version is deprecated and disabled by default. Support for v2 will be removed from Envoy at the start of Q1 2021. You may make use of v2 in Q4 2020 by following the advice in https://www.envoyproxy.io/docs/envoy/latest/faq/api/transition. (envoy.config.filter.http.lua.v2.Lua)
outbound:240.0.0.1:80: The v2 xDS major version is deprecated and disabled by default. Support for v2 will be removed from Envoy at the start of Q1 2021. You may make use of v2 in Q4 2020 by following the advice in https://www.envoyproxy.io/docs/envoy/latest/faq/api/transition. (envoy.config.filter.http.lua.v2.Lua)
outbound:240.0.0.4:80: The v2 xDS major version is deprecated and disabled by default. Support for v2 will be removed from Envoy at the start of Q1 2021. You may make use of v2 in Q4 2020 by following the advice in https://www.envoyproxy.io/docs/envoy/latest/faq/api/transition. (envoy.config.filter.http.lua.v2.Lua)
outbound:240.0.0.3:80: The v2 xDS major version is deprecated and disabled by default. Support for v2 will be removed from Envoy at the start of Q1 2021. You may make use of v2 in Q4 2020 by following the advice in https://www.envoyproxy.io/docs/envoy/latest/faq/api/transition. (envoy.config.filter.http.lua.v2.Lua)
outbound:240.0.0.6:80: The v2 xDS major version is deprecated and disabled by default. Support for v2 will be removed from Envoy at the start of Q1 2021. You may make use of v2 in Q4 2020 by following the advice in https://www.envoyproxy.io/docs/envoy/latest/faq/api/transition. (envoy.config.filter.http.lua.v2.Lua)
there is a link to Tag page in https://github.com/kumahq/kuma-website/blame/master/docs/docs/0.7.2/policies/traffic-permissions.md#L58 but Tag page https://kuma.io/docs/0.7.2/documentation/tags/ is empty.
Right now, step four in the kubernetes docs is:
kumactl config control-planes add --name=XYZ --address=http://address.to.kuma:5681
without any additional information.
Need to add following:
kubectl port-forward ..
or kubectl proxy
to make the kuma-control-plane
available to kumactl on the hostkube-control-plane
as the address.to.kumaThe download links for Kuma 1.2.3 are all kuma--foo
, where they should be kuma-1.2.3-foo
.
jpeach@greenling:~/upstream/konghq/kuma-website$ git grep kuma-- ./docs/docs/1.2.3/
docs/docs/1.2.3/installation/amazonlinux.md:or you can [download](https://download.konghq.com/mesh-alpine/kuma--centos-amd64.tar.gz) the distribution manually.
docs/docs/1.2.3/installation/centos.md:or you can [download](https://download.konghq.com/mesh-alpine/kuma--centos-amd64.tar.gz) the distribution manually.
docs/docs/1.2.3/installation/debian.md:or you can [download](https://download.konghq.com/mesh-alpine/kuma--debian-amd64.tar.gz) the distribution manually.
docs/docs/1.2.3/installation/docker.md:* [CentOS](https://download.konghq.com/mesh-alpine/kuma--centos-amd64.tar.gz)
docs/docs/1.2.3/installation/docker.md:* [RedHat](https://download.konghq.com/mesh-alpine/kuma--rhel-amd64.tar.gz)
docs/docs/1.2.3/installation/docker.md:* [Debian](https://download.konghq.com/mesh-alpine/kuma--debian-amd64.tar.gz)
docs/docs/1.2.3/installation/docker.md:* [Ubuntu](https://download.konghq.com/mesh-alpine/kuma--ubuntu-amd64.tar.gz)
docs/docs/1.2.3/installation/docker.md:* [macOS](https://download.konghq.com/mesh-alpine/kuma--darwin-amd64.tar.gz)
docs/docs/1.2.3/installation/eks.md:* [CentOS](https://download.konghq.com/mesh-alpine/kuma--centos-amd64.tar.gz)
docs/docs/1.2.3/installation/eks.md:* [RedHat](https://download.konghq.com/mesh-alpine/kuma--rhel-amd64.tar.gz)
docs/docs/1.2.3/installation/eks.md:* [Debian](https://download.konghq.com/mesh-alpine/kuma--debian-amd64.tar.gz)
docs/docs/1.2.3/installation/eks.md:* [Ubuntu](https://download.konghq.com/mesh-alpine/kuma--ubuntu-amd64.tar.gz)
docs/docs/1.2.3/installation/eks.md:* [macOS](https://download.konghq.com/mesh-alpine/kuma--darwin-amd64.tar.gz) or run `brew install kumactl`
docs/docs/1.2.3/installation/kubernetes.md:* [CentOS](https://download.konghq.com/mesh-alpine/kuma--centos-amd64.tar.gz)
docs/docs/1.2.3/installation/kubernetes.md:* [RedHat](https://download.konghq.com/mesh-alpine/kuma--rhel-amd64.tar.gz)
docs/docs/1.2.3/installation/kubernetes.md:* [Debian](https://download.konghq.com/mesh-alpine/kuma--debian-amd64.tar.gz)
docs/docs/1.2.3/installation/kubernetes.md:* [Ubuntu](https://download.konghq.com/mesh-alpine/kuma--ubuntu-amd64.tar.gz)
docs/docs/1.2.3/installation/kubernetes.md:* [macOS](https://download.konghq.com/mesh-alpine/kuma--darwin-amd64.tar.gz) or run `brew install kumactl`
docs/docs/1.2.3/installation/macos.md:* [Download Kuma](https://download.konghq.com/mesh-alpine/kuma--darwin-amd64.tar.gz)
docs/docs/1.2.3/installation/openshift.md:* [CentOS](https://download.konghq.com/mesh-alpine/kuma--centos-amd64.tar.gz)
docs/docs/1.2.3/installation/openshift.md:* [RedHat](https://download.konghq.com/mesh-alpine/kuma--rhel-amd64.tar.gz)
docs/docs/1.2.3/installation/openshift.md:* [Debian](https://download.konghq.com/mesh-alpine/kuma--debian-amd64.tar.gz)
docs/docs/1.2.3/installation/openshift.md:* [Ubuntu](https://download.konghq.com/mesh-alpine/kuma--ubuntu-amd64.tar.gz)
docs/docs/1.2.3/installation/openshift.md:* [macOS](https://download.konghq.com/mesh-alpine/kuma--darwin-amd64.tar.gz) or `brew install kumactl`
docs/docs/1.2.3/installation/redhat.md:or you can [download](https://download.konghq.com/mesh-alpine/kuma--rhel-amd64.tar.gz) the distribution manually.
docs/docs/1.2.3/installation/ubuntu.md:or you can [download](https://download.konghq.com/mesh-alpine/kuma--ubuntu-amd64.tar.gz) the distribution manually.
TrafficLog can be used to log on stdout with path: /dev/stdout
. Add this as a tip to docs
Issue comes up regularly, most recently in comments on PR #504
The locality-aware load balancing implementation in all releases of Kuma so far doesn't actually use these tags, so they have no effect whatsoever. We should remove them from the documentation.
Recently out of the blue, I started getting build errors on Netlify:
After doing some digging, there seems to be a common recurring issue where builds will exceed the 15-minute cap that Netlify sets on build times. Because our latest builds are now slightly exceeding this number, they are failing.
To make things even more difficult, the build process works flawlessly on my local machine both with yarn docs:build
and with netlify build
(using Netlify's own CLI tool). In fact, the build time locally is about half of what Netlify's is.
I've published a Netlify community forum post to get help on the issue. The Netlify team should be able to increase our build limit to 30 minutes as a solution, but I'd also like to try and make the build pipeline a little more streamlined for the site.
This is something I can't take on by myself. I'm looking at Netlify's docs, and also looking at threads like this on the VuePress repository. There is also vuepress-next but I think it's in too early of the development cycle to consider moving to.
I noticed that kumactl
generates a markdown HELP.md, which seems pretty useful. Cobra has built-in support for generating markdown documentation.
It would be pretty nice to generate reference pages for all the commands that ship as part of Kuma and include it in the website as reference material.
From discussions in the community, the interest to running Kuma in Universal or Hybrid mode is very big. We lack best practices examples of: systemd, Docker, Docker Compose. With the advancements in Kuma, we now have various deployment scenarios which we may need to go through in a systematic and practical manner.
From kumahq/kuma#2691, document
--concurrency
flagkuma.io/sidecar-proxy-concurrency
annotationFeedback from the community
Ryan Collins
that's super hard to find in the docs and DataPlane does not make any mention of it
Kuma sidecar CPU and Memory requests and limits are global , this should configurable per service via annotations, something like
kuma.io/sidecar-cpu-request
kuma.io/sidecar-cpu-limit
kuma.io/sidecar-mem-request
kuma.io/sidecar-mem-limit
This will help services which can only scale vertically. If no annotation is provided may be it can default to global setting.
Provide instruction that to disable mTLS you need to pass an empty string to enabledBackend
or remove it from YAML.
In https://kuma.io/docs/1.1.6/documentation/dps-and-data-model/#ingress, creating an ingress dataplane is described like this
The recommended way to deploy an Ingress dataplane in Kubernetes is to use kumactl, or the Helm charts as specified in multi-zone. It works as a separate deployment of a single-container pod.
What are the specific kumactl
commands that I need to use to create an ingress Dataplane? It's not obvious from the kumactl
help or from the source.
At this page: https://kuma.io/docs/1.2.3/policies/traffic-log/#add-a-logging-backend
The yaml is not valid yaml
Recently I had a task to install Kuma in EKS cluster. I noticed that whether I have multi zone or standalone setup there are steps that are missing or hard to find in documentation.
For example, in Amazon EKS installation one has to make sure to install following:
1- Kuma DNS: to resolve the virtual IPs
2- Kong Ingress controller: it can be misleading, one may try to use Kuma Ingress, but that's only for the cross zone communication and for Kuma internals and can not be used as ingress controller. Thus we should install Kong Ingress (DB Less) otherwise after enabling MTLS all Amazon NLB's will fail due to mTLS cert checking for SAN of NLB...
3- For multi zone setup, Kuma Ingress is also required.
4- Ingress resource sample / template that will be required in this case to allow traffic from outside of EKS cluster to micro services.
I can contribute to create the initial draft of what needs to be installed / configured with some syntax.
You can parametrize resource for kumactl like this:
mtls:
backends:
- name: vault-1
type: {{ caType }}
dpCert:
rotation:
expiration: 10h
name: default
type: Mesh
kumactl apply -f ~/res/mesh.yaml -v caType=builtin
I see no doc for this feature
On several locations in the docs and blogs, it's stated (taken from https://kuma.io/blog/2020/multi-cluster-cloud/):
When a new service is registered into Kuma, a new βkuma.io/zoneβ tag is added to the data plane definition so that we can use the attribute-based policy selectors (opens new window) to configure Kuma policies like Traffic Route (opens new window) to determine the behavior of cross-zone traffic (blue/green or canary across different zones, weighted traffic, as well as traffic shifting).
With link to TrafficRoute (just as an example):
https://kuma.io/docs/1.0.6/policies/traffic-route/#load-balancer-types
But I can't find any explanation about how to actually do the cross-cluster routing. Imagine a global CP acting as Ingress, forwarding requests to multiple clusters in different datacenters. How is this possible?
Several of the documentation pages do not provide full examples of the policy/object specification. Since these specifications do not appear to be publicly documented elsewhere (barring someone manually reviewing the code), the Kuma documentation should be updated to include full examples of the specification for all policies/objects.
As of 28 June, the following policies/objects did not appear to provide full examples (if the examples provided are full examples, it is not made clear to the reader/viewer):
In some cases (like Rate Limit), it appears that we document some of the fields outside of an example, which is fine for now. Ultimately, though, we should strive for consistency in how we document and present this information to Kuma users.
The default deployment, generated by kumactl, comes with a replicaCount of 1 for kuma-cp. Although the documentation mentions, that the kuma-cp is horizontally scalable, the documentation lacks the information about a recommended setting for production use.
In the Community Slack, we had a discussion about this topic and it turned out that a quorum-able count (reads: 2/3, 3/5, 4/7, etc) seems to be the recommended option. Reference: https://kuma-mesh.slack.com/archives/CN2GN4HE1/p1615466512113300
Recommendations of this kind help people like me to get a good start with kuma ;)
The file that is passed to the kuma-dp --dataplane-file
option is a mustache template that can be expanded with variables taken from the --dataplane-var
.
It would be great if this was documented, possibly with examples about how it can be useful for different deploments, e.g. the use case in examples/ecs/workload.yaml
.
I am trying to create the kuma control plane on a GKE cluster by following the standalone instructions as detailed here although after everything has completed it seems kuma is stuck at creating the default mesh. The control plane logs indicates
with INFO defaults trying to create default Mesh
repeating.
I have tried to creating a mesh manually by applying the follow with kubectl -f mesh.yml:
mesh.yml
apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:
name: my-mesh
spec:
mtls:
enabledBackend: test
backends:
- name: test
type: builtin
enabled: true
but this resulted in the following error:
Error from server (InternalError): error when creating "test.yml": Internal error occurred: failed calling webhook "mesh.defaulter.kuma-admission.kuma.io": Post https://kuma-control-plane.kuma-system.svc:443/default-kuma-io-v1alpha1-mesh?timeout=30s: context deadline exceeded
gcloud beta container clusters create test \
--no-enable-basic-auth \
--cluster-version "1.17.17-gke.1101" \
--machine-type "n1-standard-2" \
--image-type "COS" \
--disk-type "pd-standard" \
--disk-size "20" \
--metadata disable-legacy-endpoints=true, \
--service-account limited-gke-service-account \
--max-pods-per-node "30" \
--num-nodes "3" \
--enable-stackdriver-kubernetes \
--enable-private-nodes \
--master-ipv4-cidr "$MASTER_IPV4" \
--enable-ip-alias \
--default-max-pods-per-node "110" \
--enable-autoscaling \
--min-nodes "0" \
--max-nodes "3" \
--enable-network-policy \
--enable-master-authorized-networks \
--master-authorized-networks 0.0.0.0/0 \
--addons HorizontalPodAutoscaling,HttpLoadBalancing \
--enable-autoupgrade \
--enable-autorepair \
--enable-shielded-nodes
The limited-gke-service-account
has a Kubernetes Engine Admin IAM role as well as the Metric Writer role.
Error from server (InternalError): error when creating "test.yml": Internal error occurred: failed calling webhook "mesh.defaulter.kuma-admission.kuma.io": Post https://kuma-control-plane.kuma-system.svc:443/default-kuma-io-v1alpha1-mesh?timeout=30s: context deadline exceeded
Tested on both kuma 1.1.1 and 1.1.0
There doesn't seem to be any other logs indicating error besides the repeating of the trying to create default Mesh
INFO entries
Update: leaving the control plane in this state after a while results in this error message:
ERROR mesh-insight-resyncer component terminated with an error {"generationID": 1, "error": "stop channel was closed", "errorVerbose": "stop channel was closed\ngithub.com/kumahq/kuma/pkg/events.(*reader).Recv\n\t/go/src/github.com/kumahq/kuma/pkg/events/eventbus.go:57\ngithub.com/kumahq/kuma/pkg/insights.(*resyncer).Start\n\t/go/src/github.com/kumahq/kuma/pkg/insights/resyncer.go:101\ngithub.com/kumahq/kuma/pkg/core/runtime/component.(*resilientComponent).Start.func1\n\t/go/src/github.com/kumahq/kuma/pkg/core/runtime/component/resilient.go:43\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1374"}
Although it could be due to GKE restarting the pod.
Default quick start, no custom changes.
GKE
This occurs in the latest helm charts as well as with the kumactl client.
Add annotation that to modify HTTP filter you need to first configure dataplane with protocol HTTP
Hey! When I go to the Kuma documentation and click on for example the CLI
link in the left sidebar, site scrolls down but not to the CLI section. At least not every time.
To reproduce this bug go to the site and click on the links a few times. Try also the incognito window. I use Chrome Version 76.0.3809.132 (Official Build) (64-bit)
and macOS Mojave Version 10.14.5
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.