Ĝuste, post liberigo komence de majo 2019, en Konsulo vi povas rajtigi aplikojn kaj servojn kurantajn en Kubernetes denaske.
En ĉi tiu lernilo ni kreos paŝon post paŝo (Pruvo de koncepto, PoC) pruvante ĉi tiun novan funkcion. Vi estas atendita havi bazan scion pri Kubernetes kaj la Konsulo de Hashicorp. Dum vi povas uzi ajnan nuban platformon aŭ surlokan medion, en ĉi tiu lernilo ni uzos la Nuban Platformon de Google.
trarigardo
Se ni iros al , ni ricevos rapidan superrigardon de ĝia celo kaj uzkazo, same kiel kelkajn teknikajn detalojn kaj ĝeneralan superrigardon de la logiko. Mi tre rekomendas legi ĝin almenaŭ unufoje antaŭ ol daŭrigi, ĉar mi nun klarigos kaj maĉos ĉion.
Diagramo 1: Oficiala superrigardo de la Konsula rajtigometodo
Ni enrigardu .
Certe, estas utilaj informoj tie, sed ne ekzistas gvidilo pri kiel efektive uzi ĉion. Do, kiel ĉiu prudenta homo, vi traserĉas la Interreton por gvidado. Kaj tiam... Vi malsukcesas. Ĝi okazas. Ni riparu ĉi tion.
Antaŭ ol ni daŭrigu krei nian POC, ni reiru al la superrigardo de la rajtigaj metodoj de Konsulo (Diagramo 1) kaj rafini ĝin en la kunteksto de Kubernetes.
arkitekturo
En ĉi tiu lernilo, ni kreos Konsulservilon sur aparta maŝino, kiu komunikados kun Kubernetes-grupo kun la Konsul-kliento instalita. Ni tiam kreos nian simulan aplikaĵon en la pod kaj uzos nian agorditan rajtigan metodon por legi de nia Konsula ŝlosilo/valora vendejo.
La suba diagramo detaligas la arkitekturon, kiun ni kreas en ĉi tiu lernilo, kaj ankaŭ la logikon malantaŭ la rajtiga metodo, kiu estos klarigita poste.
Diagramo 2: Superrigardo de Kubernetes Rajtigo-Metodo
Rapida noto: la Konsula servilo ne bezonas vivi ekster la Kubernetes-areo por ke tio funkciu. Sed jes, li povas fari ĝin tiel kaj tiel.
Do, prenante la Konsulan superrigardan diagramon (Diagramo 1) kaj aplikante Kubernetes al ĝi, ni ricevas la supran diagramon (Diagramo 2), kaj la logiko ĉi tie estas jena:
- Ĉiu pod havos servokonton ligitan al ĝi enhavantan JWT-ĵetonon generitan kaj konatan de Kubernetes. Ĉi tiu ĵetono ankaŭ estas enmetita en la pod defaŭlte.
- Nia aplikaĵo aŭ servo en la podo iniciatas ensalutan komandon al nia Konsula kliento. La ensaluta peto ankaŭ inkluzivos nian ĵetonon kaj nomon speciale kreitaj rajtiga metodo (Kubernetes-tipo). Ĉi tiu paŝo numero 2 egalrilatas al paŝo 1 de la Konsula diagramo (Skemo 1).
- Nia Konsula kliento tiam plusendos ĉi tiun peton al nia Konsula servilo.
- MAGIO! Ĉi tie la Konsula servilo kontrolas la aŭtentikecon de la peto, kolektas informojn pri la identeco de la peto kaj komparas ĝin kun iuj rilataj antaŭdifinitaj reguloj. Malsupre estas alia diagramo por ilustri ĉi tion. Ĉi tiu paŝo respondas al paŝoj 3, 4 kaj 5 de la Konsula superrigarda diagramo (Diagramo 1).
- Nia Konsula servilo generas Konsulan ĵetonon kun permesoj laŭ niaj specifitaj rajtigaj metodoreguloj (kiujn ni difinis) pri la identeco de la petanto. Ĝi tiam sendos tiun ĵetonon reen. Ĉi tio respondas al paŝo 6 de la Konsula diagramo (Diagramo 1).
- Nia Konsula kliento plusendas la ĵetonon al la petanta aplikaĵo aŭ servo.
Nia aplikaĵo aŭ servo nun povas uzi ĉi tiun Konsulan ĵetonon por komuniki kun niaj Konsulaj datumoj, kiel determinite de la privilegioj de la ĵetono.
La magio estas malkaŝita!
Por tiuj el vi, kiuj ne estas feliĉaj kun nur kuniklo el ĉapelo kaj volas scii kiel ĝi funkcias... lasu min "montri al vi kiom profunda kuniklotruo".
Kiel menciite antaŭe, nia "magia" paŝo (Figuro 2: Paŝo 4) estas kie la Konsula servilo aŭtentikigas la peton, kolektas la petajn informojn kaj komparas ĝin kun iuj rilataj antaŭdifinitaj reguloj. Ĉi tiu paŝo respondas al paŝoj 3, 4 kaj 5 de la Konsula superrigarda diagramo (Diagramo 1). Malsupre estas diagramo (Diagramo 3), kies celo estas klare montri kio efektive okazas sub la kapuĉo specifa Kubernetes-rajtigometodo.
Diagramo 3: La magio estas rivelita!
- Kiel deirpunkto, nia Konsula kliento plusendas la ensalutan peton al nia Konsula servilo kun la Kubernetes-konto-ĵetono kaj specifa petnomo de la rajtiga metodo kiu estis kreita pli frue. Ĉi tiu paŝo egalrilatas al paŝo 3 en la antaŭa cirkvito klarigo.
- Nun la Konsula servilo (aŭ gvidanto) devas kontroli la aŭtentikecon de la ricevita ĵetono. Sekve, ĝi konsultos la Kubernetes-grupon (per la Consul-kliento) kaj, kun la taŭgaj permesoj, ni ekscios ĉu la ĵetono estas aŭtenta kaj al kiu ĝi apartenas.
- La validigita peto estas tiam resendita al la Konsula gvidanto, kaj la Konsula servilo serĉas la rajtigan metodon kun la specifita nomo de la ensaluta peto (kaj Kubernetes-tipo).
- La konsulestro identigas la specifitan rajtigan metodon (se trovite) kaj legas la aron de devigaj reguloj, kiuj estas alkroĉitaj al ĝi. Ĝi tiam legas ĉi tiujn regulojn kaj komparas ilin kun la kontrolitaj identecaj atributoj.
- TA-dah! Ni transiru al paŝo 5 en la antaŭa cirkvito klarigo.
Rulu Consul-servilon sur regula virtuala maŝino
Ekde nun, mi plejparte donos instrukciojn pri kiel krei ĉi tiun POC, ofte en kuglopunktoj, sen plenaj frazaj klarigoj. Ankaŭ, kiel notite antaŭe, mi uzos GCP por krei la tutan infrastrukturon, sed vi povas krei la saman infrastrukturon ie ajn.
- Lanĉu la virtualan maŝinon (instanco/servilo).
- Kreu regulon por la fajroŝirmilo (sekureca grupo en AWS):
- Mi ŝatas atribui la saman maŝinnomon kaj al la regulo kaj al la retetikedo, ĉi-kaze "skywiz-consul-server-poc".
- Trovu la IP-adreson de via loka komputilo kaj aldonu ĝin al la listo de fontaj IP-adresoj por ke ni povu aliri la uzantinterfacon (UI).
- Malfermu havenon 8500 por UI. Klaku Krei. Ni baldaŭ ŝanĝos ĉi tiun fajroŝirmilon denove [].
- Aldonu fajroŝirmigan regulon al la petskribo. Reiru al la VM-panelo sur Consul Server kaj aldonu "skywiz-consul-server-poc" al la kampo de retaj etikedoj. Klaku Konservi.
- Instalu Consul sur virtuala maŝino, kontrolu ĉi tie. Memoru, ke vi bezonas konsulan version ≥ 1.5 [ligo]
- Ni kreu ununuran nodon Konsulo - la agordo estas jena.
groupadd --system consul
useradd -s /sbin/nologin --system -g consul consul
mkdir -p /var/lib/consul
chown -R consul:consul /var/lib/consul
chmod -R 775 /var/lib/consul
mkdir /etc/consul.d
chown -R consul:consul /etc/consul.d- Por pli detala gvidilo pri instalo de Konsulo kaj agordo de aro de 3 nodoj, vidu .
- Kreu dosieron /etc/consul.d/agent.json jene []:
### /etc/consul.d/agent.json
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}- Komencu nian Konsulservilon:
consul agent
-server
-ui
-client 0.0.0.0
-data-dir=/var/lib/consul
-bootstrap-expect=1
-config-dir=/etc/consul.d- Vi devus vidi amason da eligo kaj fini kun "... ĝisdatigo blokita de ACL-oj."
- Trovu la eksteran IP-adreson de la Konsula servilo kaj malfermu retumilon kun ĉi tiu IP-adreso sur la haveno 8500. Certiĝu, ke la UI malfermiĝas.
- Provu aldoni ŝlosil/valoran paron. Devas esti eraro. Ĉi tio estas ĉar ni ŝarĝis la Konsulservilon per ACL kaj malŝaltis ĉiujn regulojn.
- Reiru al via ŝelo sur la Konsula servilo kaj komencu la procezon en la fono aŭ iun alian manieron funkciigi ĝin kaj enigu la jenon:
consul acl bootstrap- Trovu la valoron "SecretID" kaj revenu al la UI. En la langeto ACL, enigu la sekretan ID de la ĵetono, kiun vi ĵus kopiis. Kopiu SecretID aliloke, ni bezonos ĝin poste.
- Nun aldonu ŝlosilon/valoran paron. Por ĉi tiu POC, aldonu la jenon: ŝlosilo: "custom-ns/test_key", valoro: "Mi estas en la dosierujo custom-ns!"
Lanĉante Kubernetes-grupon por nia aplikaĵo kun la Consul-kliento kiel Daemonset
- Kreu K8s (Kubernetes) areton. Ni kreos ĝin en la sama zono kiel la servilo por pli rapida aliro, kaj tiel ni povas uzi la saman subreton por facile konekti kun internaj IP-adresoj. Ni nomos ĝin "skywiz-app-with-consul-client-poc".
- Kiel flanka noto, jen bona lernilo, kiun mi renkontis dum agordado de POC-Konsulo-grupo kun Consul Connect.
- Ni ankaŭ uzos Hashicorp-tiran diagramon kun plilongigita valordosiero.
- Instalu kaj agordu Helm. Agordaj paŝoj:
kubectl create serviceaccount tiller --namespace kube-system
kubectl create clusterrolebinding tiller-admin-binding
--clusterrole=cluster-admin --serviceaccount=kube-system:tiller
./helm init --service-account=tiller
./helm update- stirila diagramo:
- Uzu la sekvan valordosieron (rimarku, ke mi malŝaltis plej multajn):
### poc-helm-consul-values.yaml
global:
enabled: false
image: "consul:latest"
# Expose the Consul UI through this LoadBalancer
ui:
enabled: false
# Allow Consul to inject the Connect proxy into Kubernetes containers
connectInject:
enabled: false
# Configure a Consul client on Kubernetes nodes. GRPC listener is required for Connect.
client:
enabled: true
join: ["<PRIVATE_IP_CONSUL_SERVER>"]
extraConfig: |
{
"acl" : {
"enabled": true,
"default_policy": "deny",
"enable_token_persistence": true
}
}
# Minimal Consul configuration. Not suitable for production.
server:
enabled: false
# Sync Kubernetes and Consul services
syncCatalog:
enabled: false- Apliki stirilan diagramon:
./helm install -f poc-helm-consul-values.yaml ./consul-helm - name skywiz-app-with-consul-client-poc- Kiam ĝi provos funkcii, ĝi bezonos permesojn por la Konsula servilo, do ni aldonu ilin.
- Notu la "Pod Address Range" situantan sur la clusterpanelo kaj referencu al nia "skywiz-consul-server-poc" fajroŝirmiga regulo.
- Aldonu la adresintervalon por la pod al la listo de IP-adresoj kaj malfermu pordojn 8301 kaj 8300.
- Iru al la Konsula UI kaj post kelkaj minutoj vi vidos nian areton aperi en la nodoj langeto.
Agordante Rajtigan Metodon per Integrado de Konsulo kun Kubernetes
- Revenu al la Konsula servila ŝelo kaj eksportu la ĵetonon, kiun vi konservis pli frue:
export CONSUL_HTTP_TOKEN=<SecretID>- Ni bezonos informojn de nia Kubernetes-grupo por krei ekzemplon de la aŭth-metodo:
- kubernetes-gastiganto
kubectl get endpoints | grep kubernetes- kubernetes-servo-konto-jwt
kubectl get sa <helm_deployment_name>-consul-client -o yaml | grep "- name:"
kubectl get secret <secret_name_from_prev_command> -o yaml | grep token:- La ĵetono estas base64 kodita, do deĉifri ĝin per via plej ŝatata ilo []
- kubernetes-ca-cert
kubectl get secret <secret_name_from_prev_command> -o yaml | grep ca.crt:- Prenu la atestilon "ca.crt" (post base64-malkodado) kaj skribu ĝin en la dosieron "ca.crt".
- Nun kreu la aŭth-metodon, anstataŭigante la anstataŭaĵojn per la valoroj, kiujn vi ĵus ricevis.
consul acl auth-method create
-type "kubernetes"
-name "auth-method-skywiz-consul-poc"
-description "This is an auth method using kubernetes for the cluster skywiz-app-with-consul-client-poc"
-kubernetes-host "<k8s_endpoint_retrieved earlier>"
[email protected]
-kubernetes-service-account-
jwt="<decoded_token_retrieved_earlier>"- Poste ni devas krei regulon kaj ligi ĝin al la nova rolo. Por ĉi tiu parto vi povas uzi Consul UI, sed ni uzos la komandlinion.
- Skribu regulon
### kv-custom-ns-policy.hcl
key_prefix "custom-ns/" {
policy = "write"
}- Apliki la regulon
consul acl policy create
-name kv-custom-ns-policy
-description "This is an example policy for kv at custom-ns/"
-rules @kv-custom-ns-policy.hcl- Trovu la ID de la regulo, kiun vi ĵus kreis el la eligo.
- Kreu rolon kun nova regulo.
consul acl role create
-name "custom-ns-role"
-description "This is an example role for custom-ns namespace"
-policy-id <policy_id>- Nun ni asocios nian novan rolon kun la aŭth-metoda ekzemplo. Notu, ke la flago "elektilo" determinas ĉu nia ensaluta peto ricevos ĉi tiun rolon. Kontrolu ĉi tie por aliaj elekteblaj opcioj:
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-ns-role'
-selector='serviceaccount.namespace=="custom-ns"'Laste agordoj
Alirrajtoj
- Krei alirrajtojn. Ni devas doni Konsulo-permeson kontroli kaj identigi la identecon de la serva konto K8s.
- Skribu la jenon al la dosiero :
###skywiz-poc-consul-server_rbac.yaml
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: review-tokens
namespace: default
subjects:
- kind: ServiceAccount
name: skywiz-app-with-consul-client-poc-consul-client
namespace: default
roleRef:
kind: ClusterRole
name: system:auth-delegator
apiGroup: rbac.authorization.k8s.io
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: service-account-getter
namespace: default
rules:
- apiGroups: [""]
resources: ["serviceaccounts"]
verbs: ["get"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: get-service-accounts
namespace: default
subjects:
- kind: ServiceAccount
name: skywiz-app-with-consul-client-poc-consul-client
namespace: default
roleRef:
kind: ClusterRole
name: service-account-getter
apiGroup: rbac.authorization.k8s.io- Ni kreu alirrajtojn
kubectl create -f skywiz-poc-consul-server_rbac.yamlKonektante al Konsula Kliento
- Kiel notite Estas pluraj ebloj por konekti al daemonset, sed ni pluiros al la sekva simpla solvo:
- Apliku la sekvan dosieron [].
### poc-consul-client-ds-svc.yaml
apiVersion: v1
kind: Service
metadata:
name: consul-ds-client
spec:
selector:
app: consul
chart: consul-helm
component: client
hasDNS: "true"
release: skywiz-app-with-consul-client-poc
ports:
- protocol: TCP
port: 80
targetPort: 8500- Poste uzu la sekvan enkonstruitan komandon por krei konfigmapon []. Bonvolu noti, ke ni aludas al la nomo de nia servo, anstataŭigu ĝin se necese.
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
labels:
addonmanager.kubernetes.io/mode: EnsureExists
name: kube-dns
namespace: kube-system
data:
stubDomains: |
{"consul": ["$(kubectl get svc consul-ds-client -o jsonpath='{.spec.clusterIP}')"]}
EOFTestante la aŭth-metodon
Nun ni vidu la magion en ago!
- Kreu plurajn pliajn ŝlosilajn dosierujojn kun la sama ĉefnivela ŝlosilo (t.e. /sample_key) kaj valoron de via elekto. Kreu taŭgajn politikojn kaj rolojn por novaj ŝlosilaj vojoj. Ni faros la ligadojn poste.
Propra provo de nomspaco:
- Ni kreu nian propran nomspacon:
kubectl create namespace custom-ns- Ni kreu pod en nia nova nomspaco. Skribu la agordon por la pod.
###poc-ubuntu-custom-ns.yaml
apiVersion: v1
kind: Pod
metadata:
name: poc-ubuntu-custom-ns
namespace: custom-ns
spec:
containers:
- name: poc-ubuntu-custom-ns
image: ubuntu
command: ["/bin/bash", "-ec", "sleep infinity"]
restartPolicy: Never- Kreu sub:
kubectl create -f poc-ubuntu-custom-ns.yaml- Kiam la ujo funkcias, iru tien kaj instalu buklon.
kubectl exec poc-ubuntu-custom-ns -n custom-ns -it /bin/bash
apt-get update && apt-get install curl -y- Nun ni sendos ensalutpeton al Konsulo uzante la rajtigan metodon, kiun ni kreis pli frue [].
- Por vidi la enigitan ĵetonon de via servokonto:
cat /run/secrets/kubernetes.io/serviceaccount/token- Skribu la jenon al dosiero ene de la ujo:
### payload.json
{
"AuthMethod": "auth-method-test",
"BearerToken": "<jwt_token>"
}- Ensaluti!
curl
--request POST
--data @payload.json
consul-ds-client.default.svc.cluster.local/v1/acl/login- Por plenumi la suprajn paŝojn en unu linio (ĉar ni faros plurajn provojn), vi povas fari la jenon:
echo "{
"AuthMethod": "auth-method-skywiz-consul-poc",
"BearerToken": "$(cat /run/secrets/kubernetes.io/serviceaccount/token)"
}"
| curl
--request POST
--data @-
consul-ds-client.default.svc.cluster.local/v1/acl/login- Verkoj! Almenaŭ devus. Nun prenu la SecretID kaj provu aliri la ŝlosilon/valoron al kiu ni devus havi aliron.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-ns/test_key --header “X-Consul-Token: <SecretID_from_prev_response>”- Vi povas baze64 malkodi "Valoro" kaj vidi, ke ĝi kongruas kun la valoro en custom-ns/test_key en la UI. Se vi uzis la saman valoron supre en ĉi tiu lernilo, via kodita valoro estus IkknbSBpbiB0aGUgY3VzdG9tLW5zIGZvbGRlciEi.
Testo pri uzantserva konto:
- Kreu kutiman Servan Konton uzante la jenan komandon [].
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
name: custom-sa
EOF- Kreu novan agordan dosieron por la pod. Bonvolu noti, ke mi inkludis buklan instaladon por ŝpari laboron :)
###poc-ubuntu-custom-sa.yaml
apiVersion: v1
kind: Pod
metadata:
name: poc-ubuntu-custom-sa
namespace: default
spec:
serviceAccountName: custom-sa
containers:
- name: poc-ubuntu-custom-sa
image: ubuntu
command: ["/bin/bash","-ec"]
args: ["apt-get update && apt-get install curl -y; sleep infinity"]
restartPolicy: Never- Post tio, rulu ŝelon en la ujo.
kubectl exec -it poc-ubuntu-custom-sa /bin/bash- Ensaluti!
echo "{
"AuthMethod": "auth-method-skywiz-consul-poc",
"BearerToken": "$(cat /run/secrets/kubernetes.io/serviceaccount/token)"
}"
| curl
--request POST
--data @-
consul-ds-client.default.svc.cluster.local/v1/acl/login- Permeso Rifuzita. Ho, ni forgesis aldoni novajn regulojn ligantajn kun la taŭgaj permesoj, ni faru tion nun.
Ripetu la antaŭajn paŝojn supre:
a) Kreu identan Politikon por la prefikso “custom-sa/”.
b) Kreu Rolon, nomu ĝin "custom-sa-role"
c) Aligu la Politikon al la Rolo.
- Kreu Regul-Ligadon (nur ebla de cli/api). Notu la malsaman signifon de la elekta flago.
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='custom-sa-role'
-selector='serviceaccount.name=="custom-sa"'- Ensalutu denove el la ujo "poc-ubuntu-custom-sa". Sukceso!
- Rigardu nian aliron al la kutimo-sa/ŝlosila vojo.
curl
consul-ds-client.default.svc.cluster.local/v1/kv/custom-sa/test_key --header “X-Consul-Token: <SecretID>”- Vi ankaŭ povas certigi, ke ĉi tiu signo ne donas aliron al kv en "custom-ns/". Nur ripetu la supran komandon post anstataŭigi "custom-sa" per la prefikso "custom-ns".
Permeso Rifuzita.
Ekzemplo de supermetita:
- Indas noti, ke ĉiuj regul-devigaj mapadoj estos aldonitaj al la ĵetono kun ĉi tiuj rajtoj.
- Nia ujo "poc-ubuntu-custom-sa" estas en la defaŭlta nomspaco - do ni uzu ĝin por malsama regulligo.
- Ripetu antaŭajn paŝojn:
a) Kreu identan Politikon por la ŝlosila prefikso "defaŭlta/".
b) Kreu Rolon, nomu ĝin "default-ns-role"
c) Aligu la Politikon al la Rolo. - Krei Regul-Ligadon (nur ebla de cli/api)
consul acl binding-rule create
-method=auth-method-skywiz-consul-poc
-bind-type=role
-bind-name='default-ns-role'
-selector='serviceaccount.namespace=="default"'- Reiru al nia "poc-ubuntu-custom-sa" ujo kaj provu aliri la "defaŭltan/" kv-vojon.
- Permeso Rifuzita.
Vi povas vidi la specifitajn akreditaĵojn por ĉiu ĵetono en la UI sub ACL > Tokens. Kiel vi povas vidi, nia nuna ĵetono havas nur unu "kutim-sa-rolon" ligitan al ĝi. La ĵetono, kiun ni nuntempe uzas, estis generita kiam ni ensalutis kaj estis nur unu regulligado kiu kongruis tiam. Ni devas denove ensaluti kaj uzi la novan signon. - Certigu, ke vi povas legi kaj el la kv-vojoj "custom-sa/" kaj "default/".
Sukceso!
Ĉi tio estas ĉar nia "poc-ubuntu-custom-sa" kongruas kun la "custom-sa" kaj "default-ns" regulligoj.
konkludo
TTL-ĵetono mgmt?
Al la momento de ĉi tiu skribado, ne ekzistas integra maniero determini la TTL por ĵetonoj generitaj de ĉi tiu rajtiga metodo. Estus mirinda ŝanco provizi sekuran aŭtomatigon de Konsula rajtigo.
Estas eblo por permane krei ĵetonon per TTL:
Eksvalida Tempo - La tempo, kiam ĉi tiu ĵetono estos nuligita. (Laŭvola; aldonita en Konsulo 1.5.0)- Ekzistas nur por mana kreado/ĝisdatigo
Espereble en proksima estonteco ni povos kontroli kiel ĵetonoj estas generitaj (laŭ regulo aŭ rajtiga metodo) kaj aldoni TTL.
Ĝis tiam, estas sugestite, ke vi uzu elsalutpunkton en via logiko.
Legu ankaŭ aliajn artikolojn en nia blogo:
fonto: www.habr.com