Apache Bigtop et choisir une distribution Hadoop aujourd'hui

Ce n'est probablement un secret pour personne que l'année dernière a été une année de grands changements pour Apache Hadoop. L'année dernière, Cloudera et Hortonworks ont fusionné (essentiellement l'acquisition de ce dernier) et Mapr, en raison de graves problèmes financiers, a été vendu à Hewlett Packard. Et si quelques années plus tôt, dans le cas des installations sur site, il fallait souvent choisir entre Cloudera et Hortonworks, aujourd'hui, hélas, nous n'avons pas ce choix. Une autre surprise a été le fait que Cloudera a annoncé en février de cette année qu'il cesserait de publier les assemblages binaires de sa distribution dans le référentiel public, et qu'ils ne sont désormais disponibles que via un abonnement payant. Bien entendu, il est toujours possible de télécharger les dernières versions de CDH et HDP sorties avant fin 2019, et leur support est attendu pendant un à deux ans. Mais que faire ensuite ? Pour ceux qui payaient auparavant un abonnement, rien n’a changé. Et pour ceux qui ne souhaitent pas passer à la version payante de la distribution, mais souhaitent en même temps pouvoir recevoir les dernières versions des composants du cluster, ainsi que des correctifs et autres mises à jour, nous avons préparé cet article. Nous y examinerons les options possibles pour sortir de cette situation.

L'article est plutôt une critique. Il ne contiendra pas de comparaison des distributions ni d'analyse détaillée de celles-ci, et il n'y aura pas de recettes pour les installer et les configurer. Que va-t-il se passer ? Nous parlerons brièvement d'une distribution telle qu'Arenadata Hadoop, qui mérite à juste titre notre attention en raison de sa disponibilité, ce qui est très rare aujourd'hui. Et puis nous parlerons de Vanilla Hadoop, principalement de la façon dont il peut être « cuisiné » à l'aide d'Apache Bigtop. Prêt? Alors bienvenue au chat.

Arenadata Hadoop

Il s'agit d'un kit de distribution de développement national complètement nouveau et encore peu connu. Malheureusement, pour le moment, sur Habré, il n'y a que Cet article.

Plus d'informations peuvent être trouvées sur le site officiel En ligne projet. Les dernières versions de la distribution sont basées sur Hadoop 3.1.2 pour la version 3 et 2.8.5 pour la version 2.

Des informations sur la feuille de route peuvent être trouvées ici.

Interface du gestionnaire de cluster Arenadata

Le produit principal d'Arenadata est Gestionnaire de cluster Arenadata (ADCM), qui est utilisé pour installer, configurer et surveiller diverses solutions logicielles de l'entreprise. ADCM est distribué gratuitement et ses fonctionnalités sont étendues par l'ajout de bundles, qui sont un ensemble de playbooks ansible. Les offres groupées sont divisées en deux types : entreprise et communauté. Ces derniers sont disponibles en téléchargement gratuit sur le site Arenadata. Il est également possible de développer votre propre bundle et de le connecter à ADCM.

Pour le déploiement et la gestion de Hadoop 3, une version communautaire du bundle est proposée conjointement avec ADCM, mais pour Hadoop 2, il n'existe que apache comme alternative. Quant aux référentiels avec packages, ils sont ouverts au public, ils peuvent être téléchargés et installés de la manière habituelle pour tous les composants du cluster. Dans l'ensemble, la distribution semble très intéressante. Je suis sûr qu'il y aura ceux qui sont habitués à des solutions telles que Cloudera Manager et Ambari, et qui apprécieront ADCM lui-même. Pour certains, ce sera aussi un énorme plus que la distribution inclus dans le registre des logiciels pour la substitution des importations.

Si nous parlons des inconvénients, ils seront les mêmes que pour toutes les autres distributions Hadoop. À savoir:

• Ce qu’on appelle le « verrouillage du fournisseur ». À l’aide des exemples de Cloudera et Hortonworks, nous avons déjà réalisé qu’il existe toujours un risque de changer la politique de l’entreprise.
• Retard important par rapport à Apache en amont.

Hadoop vanille

Comme vous le savez, Hadoop n'est pas un produit monolithique, mais en fait toute une galaxie de services autour de son système de fichiers distribué HDFS. Peu de gens auront assez d’un seul cluster de fichiers. Certains ont besoin de Hive, d'autres de Presto, et puis il y a HBase et Phoenix ; Spark est de plus en plus utilisé. Pour l'orchestration et le chargement des données, on retrouve parfois Oozie, Sqoop et Flume. Et si la question de la sécurité se pose, on pense immédiatement à Kerberos en collaboration avec Ranger.

Les versions binaires des composants Hadoop sont disponibles sur le site Internet de chacun des projets de l'écosystème sous forme d'archives tar. Vous pouvez les télécharger et commencer l'installation, mais à une condition : en plus d'assembler indépendamment des packages à partir de binaires « bruts », ce que vous souhaiterez probablement faire, vous n'aurez aucune confiance dans la compatibilité des versions téléchargées des composants avec chacun. autre. L'option préférée consiste à construire à l'aide d'Apache Bigtop. Bigtop vous permettra de créer à partir de référentiels Apache Maven, d'exécuter des tests et de créer des packages. Mais ce qui est très important pour nous, Bigtop assemblera les versions de composants qui seront compatibles entre elles. Nous en parlerons plus en détail ci-dessous.

Chapiteau Apache

Apache Bigtop est un outil permettant de créer, de conditionner et de tester un certain nombre de
des projets open source, tels que Hadoop et Greenplum. Bigtop en a plein
libère. Au moment de la rédaction de cet article, la dernière version stable était la version 1.4,
et en master il y en avait 1.5. Différentes versions des versions utilisent différentes versions
Composants. Par exemple, pour la version 1.4, les composants principaux de Hadoop ont la version 2.8.5 et dans la version principale
2.10.0. La composition des composants pris en charge évolue également. Quelque chose de dépassé et
ce qui n'est pas renouvelable s'en va, et à sa place vient quelque chose de nouveau, plus demandé, et
ce n'est pas nécessairement quelque chose de la famille Apache elle-même.

De plus, Bigtop possède de nombreux fourchettes.

Lorsque nous avons commencé à nous familiariser avec Bigtop, nous avons tout d'abord été surpris par sa prévalence et sa popularité modestes, par rapport à d'autres projets Apache, ainsi que par sa très petite communauté. Il s'ensuit qu'il existe peu d'informations sur le produit et que la recherche de solutions aux problèmes survenus sur les forums et les listes de diffusion peut ne rien donner du tout. Au début, il s'est avéré difficile pour nous de terminer l'assemblage complet de la distribution en raison des fonctionnalités de l'outil lui-même, mais nous en reparlerons un peu plus tard.

En guise de teaser, ceux qui à un moment donné étaient intéressés par des projets de l'univers Linux tels que Gentoo et LFS peuvent trouver nostalgiquement agréable de travailler avec cette chose et se souvenir de ces moments « épiques » où nous cherchions nous-mêmes (ou même écrivions) ebuilds et reconstruit régulièrement Mozilla avec de nouveaux correctifs.

Le gros avantage de Bigtop est l’ouverture et la polyvalence des outils sur lesquels il s’appuie. Il est basé sur Gradle et Apache Maven. Gradle est bien connu comme l'outil utilisé par Google pour créer Android. Il est flexible et, comme on dit, « éprouvé au combat ». Maven est un outil standard pour créer des projets dans Apache lui-même, et comme la plupart de ses produits sont publiés via Maven, cela ne pourrait pas non plus se faire sans lui ici. Il convient de prêter attention au POM (project object model) - un fichier XML « fondamental » décrivant tout ce dont Maven a besoin pour travailler avec votre projet, autour duquel tout le travail est construit. Exactement à
certaines parties de Maven et il existe certains obstacles que les nouveaux utilisateurs de Bigtop rencontrent généralement.

Pratique

Alors, par où commencer ? Accédez à la page de téléchargement et téléchargez la dernière version stable sous forme d'archive. Vous pouvez également y trouver des artefacts binaires collectés par Bigtop. À propos, parmi les gestionnaires de packages courants, YUM et APT sont pris en charge.

Alternativement, vous pouvez télécharger la dernière version stable directement depuis
github :

$ git clone --branch branch-1.4 https://github.com/apache/bigtop.git

Clonage sous chapiteau…

remote: Enumerating objects: 46, done.
remote: Counting objects: 100% (46/46), done.
remote: Compressing objects: 100% (41/41), done.
remote: Total 40217 (delta 14), reused 10 (delta 1), pack-reused 40171
Получение объектов: 100% (40217/40217), 43.54 MiB | 1.05 MiB/s, готово.
Определение изменений: 100% (20503/20503), готово.
Updating files: 100% (1998/1998), готово.

Le répertoire ./bigtop résultant ressemble à ceci :

./bigtop-bigpetstore — applications de démonstration, exemples synthétiques
./bigtop-ci — Boîte à outils CI, jenkins
./bigtop-data-generators — génération de données, synthétiques, pour essais de fumée, etc.
./bigtop-deploy - outils de déploiement
./bigtop-packages — configs, scripts, patchs pour l'assemblage, la partie principale de l'outil
./bigtop-test-framework — cadre de test
./bigtop-tests — les tests eux-mêmes, charge et fumée
./bigtop_toolchain — environnement d'assemblage, préparant l'environnement pour que l'outil fonctionne
./build — construire un répertoire de travail
./dl — répertoire des sources téléchargées
./docker — création d'images Docker, tests
./gradle - configuration progressive
./output – le répertoire où vont les artefacts de build
./provisioner — approvisionnement

La chose la plus intéressante pour nous à ce stade est la configuration principale ./bigtop/bigtop.bom, dans lequel nous voyons tous les composants pris en charge avec les versions. C'est ici que nous pouvons spécifier une version différente du produit (si nous voulons soudainement essayer de le construire) ou une version de build (si, par exemple, nous avons ajouté un correctif important).

Le sous-répertoire présente également un grand intérêt ./bigtop/bigtop-packages, qui est directement lié au processus d'assemblage des composants et des packages avec eux.

Donc, nous avons téléchargé l'archive, l'avons décompressée ou créé un clone à partir de github, pouvons-nous commencer à construire ?

Non, préparons d'abord l'environnement.

Préparation de l'environnement

Et ici, nous avons besoin d'une petite retraite. Pour créer presque n'importe quel produit plus ou moins complexe, vous avez besoin d'un certain environnement - dans notre cas, il s'agit du JDK, des mêmes bibliothèques partagées, fichiers d'en-tête, etc., des outils, par exemple ant, ivy2 et bien plus encore. L'une des options permettant d'obtenir l'environnement dont vous avez besoin pour Bigtop consiste à installer les composants nécessaires sur l'hôte de build. Je peux me tromper sur la chronologie, mais il semble qu'avec la version 1.0, il existait également une option permettant de créer des images Docker préconfigurées et accessibles, qui peuvent être trouvées ici.

Quant à la préparation de l'environnement, il existe un assistant pour cela - Puppet.

Vous pouvez utiliser les commandes suivantes, exécutées à partir du répertoire racine
outil, ./bigtop:

./gradlew toolchain
./gradlew toolchain-devtools
./gradlew toolchain-puppetmodules

Ou directement via Puppet :

puppet apply --modulepath=<path_to_bigtop> -e "include bigtop_toolchain::installer"
puppet apply --modulepath=<path_to_bigtop> -e "include bigtop_toolchain::deployment-tools"
puppet apply --modulepath=<path_to_bigtop> -e "include bigtop_toolchain::development-tools"

Malheureusement, des difficultés peuvent déjà surgir à ce stade. Le conseil général ici est d'utiliser une distribution prise en charge, à jour sur l'hôte de build, ou d'essayer la route Docker.

assemblage

Que pouvons-nous essayer de collecter ? La réponse à cette question sera donnée par le résultat de la commande

./gradlew tasks

Dans la section Tâches du package, vous trouverez un certain nombre de produits qui sont des artefacts finaux de Bigtop.
Ils peuvent être identifiés par le suffixe -rpm ou -pkg-ind (dans le cas d'un bâtiment
dans le menu fixe). Dans notre cas, le plus intéressant est Hadoop.

Essayons de construire dans l'environnement de notre serveur de build :

./gradlew hadoop-rpm

Bigtop lui-même téléchargera les sources nécessaires à un composant spécifique et commencera l'assemblage. Ainsi, le fonctionnement de l'outil dépend des référentiels Maven et d'autres sources, c'est-à-dire qu'il nécessite un accès à Internet.

Pendant le fonctionnement, une sortie standard est générée. Parfois, ces messages et les messages d'erreur peuvent vous aider à comprendre ce qui n'a pas fonctionné. Et parfois, vous avez besoin d’informations supplémentaires. Dans ce cas, cela vaut la peine d'ajouter des arguments --info ou --debug, et peut également être utile –stacktrace. Il existe un moyen pratique de générer un ensemble de données pour un accès ultérieur aux listes de diffusion, la clé --scan.

Avec son aide, bigtop collectera toutes les informations et les mettra en niveau, après quoi il fournira un lien,
à la suite de quoi, une personne compétente pourra comprendre pourquoi le montage a échoué.
Veuillez noter que cette option peut exposer des informations dont vous ne souhaitez pas, telles que des noms d'utilisateur, des nœuds, des variables d'environnement, etc., alors soyez prudent.

Les erreurs sont souvent la conséquence de l’incapacité d’obtenir les composants nécessaires à l’assemblage. En règle générale, vous pouvez résoudre le problème en créant un correctif pour corriger quelque chose dans les sources, par exemple les adresses dans pom.xml dans le répertoire racine des sources. Cela se fait en le créant et en le plaçant dans le répertoire approprié ./bigtop/bigtop-packages/src/common/oozie/ patch, par exemple, sous la forme patch2-fix.diff.

--- a/pom.xml
+++ b/pom.xml
@@ -136,7 +136,7 @@
<repositories>
<repository>
<id>central</id>
- <url>http://repo1.maven.org/maven2</url>
+ <url>https://repo1.maven.org/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>

Très probablement, au moment de lire cet article, vous n’aurez pas à effectuer vous-même la réparation ci-dessus.

Lors de l'introduction de correctifs et de modifications dans le mécanisme d'assemblage, vous devrez peut-être « réinitialiser » l'assemblage à l'aide de la commande cleanup :

./gradlew hadoop-clean
> Task :hadoop_vardefines
> Task :hadoop-clean
BUILD SUCCESSFUL in 5s
2 actionable tasks: 2 executed

Cette opération annulera toutes les modifications apportées à l'assemblage de ce composant, après quoi l'assemblage sera à nouveau effectué. Cette fois, nous allons essayer de construire le projet dans une image Docker :

./gradlew -POS=centos-7 -Pprefix=1.2.1 hadoop-pkg-ind
> Task :hadoop-pkg-ind
Building 1.2.1 hadoop-pkg on centos-7 in Docker...
+++ dirname ./bigtop-ci/build.sh
++ cd ./bigtop-ci/..
++ pwd
+ BIGTOP_HOME=/tmp/bigtop
+ '[' 6 -eq 0 ']'
+ [[ 6 -gt 0 ]]
+ key=--prefix
+ case $key in
+ PREFIX=1.2.1
+ shift
+ shift
+ [[ 4 -gt 0 ]]
+ key=--os
+ case $key in
+ OS=centos-7
+ shift
+ shift
+ [[ 2 -gt 0 ]]
+ key=--target
+ case $key in
+ TARGET=hadoop-pkg
+ shift
+ shift
+ [[ 0 -gt 0 ]]
+ '[' -z x ']'
+ '[' -z x ']'
+ '[' '' == true ']'
+ IMAGE_NAME=bigtop/slaves:1.2.1-centos-7
++ uname -m
+ ARCH=x86_64
+ '[' x86_64 '!=' x86_64 ']'
++ docker run -d bigtop/slaves:1.2.1-centos-7 /sbin/init
+
CONTAINER_ID=0ce5ac5ca955b822a3e6c5eb3f477f0a152cd27d5487680f77e33fbe66b5bed8
+ trap 'docker rm -f
0ce5ac5ca955b822a3e6c5eb3f477f0a152cd27d5487680f77e33fbe66b5bed8' EXIT
....
много вывода
....
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-mapreduce-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-namenode-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-secondarynamenode-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-zkfc-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-journalnode-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-datanode-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-httpfs-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-resourcemanager-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-nodemanager-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-proxyserver-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-timelineserver-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-mapreduce-historyserver-2.8.5-
1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-client-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-conf-pseudo-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-doc-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-libhdfs-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-libhdfs-devel-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-fuse-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-debuginfo-2.8.5-1.el7.x86_64.rpm
+ umask 022
+ cd /bigtop/build/hadoop/rpm//BUILD
+ cd hadoop-2.8.5-src
+ /usr/bin/rm -rf /bigtop/build/hadoop/rpm/BUILDROOT/hadoop-2.8.5-1.el7.x86_64
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.uQ2FCn
+ exit 0
+ umask 022
Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.CwDb22
+ cd /bigtop/build/hadoop/rpm//BUILD
+ rm -rf hadoop-2.8.5-src
+ exit 0
[ant:touch] Creating /bigtop/build/hadoop/.rpm
:hadoop-rpm (Thread[Task worker for ':',5,main]) completed. Took 38 mins 1.151 secs.
:hadoop-pkg (Thread[Task worker for ':',5,main]) started.
> Task :hadoop-pkg
Task ':hadoop-pkg' is not up-to-date because:
Task has not declared any outputs despite executing actions.
:hadoop-pkg (Thread[Task worker for ':',5,main]) completed. Took 0.0 secs.
BUILD SUCCESSFUL in 40m 37s
6 actionable tasks: 6 executed
+ RESULT=0
+ mkdir -p output
+ docker cp
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb:/bigtop/build .
+ docker cp
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb:/bigtop/output .
+ docker rm -f ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
+ '[' 0 -ne 0 ']'
+ docker rm -f ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
Error: No such container:
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
BUILD SUCCESSFUL in 41m 24s
1 actionable task: 1 executed

Le build a été réalisé sous CentOS, mais peut également être réalisé sous Ubuntu :

./gradlew -POS=ubuntu-16.04 -Pprefix=1.2.1 hadoop-pkg-ind

En plus de créer des packages pour diverses distributions Linux, l'outil peut créer un référentiel avec des packages compilés, par exemple :

./gradlew yum

Vous pouvez également vous souvenir des tests de fumée et du déploiement dans Docker.

Créez un cluster de trois nœuds :

./gradlew -Pnum_instances=3 docker-provisioner

Exécutez des tests de fumée dans un cluster de trois nœuds :

./gradlew -Pnum_instances=3 -Prun_smoke_tests docker-provisioner

Supprimer un cluster :

./gradlew docker-provisioner-destroy

Obtenez les commandes pour vous connecter à l'intérieur des conteneurs Docker :

./gradlew docker-provisioner-ssh

Afficher l'état :

./gradlew docker-provisioner-status

Vous pouvez en savoir plus sur les tâches de déploiement dans la documentation.

Si l'on parle de tests, il y en a un assez grand nombre, principalement de fumée et d'intégration. Leur analyse dépasse le cadre de cet article. Permettez-moi simplement de dire que l'assemblage d'un kit de distribution n'est pas une tâche aussi difficile qu'il y paraît à première vue. Nous avons réussi à assembler et à passer des tests sur tous les composants que nous utilisons dans notre production, et nous n'avons également eu aucun problème pour les déployer et effectuer les opérations de base dans l'environnement de test.

En plus des composants existants dans Bigtop, il est possible d'ajouter n'importe quoi d'autre, même votre propre développement logiciel. Tout cela est parfaitement automatisé et s’inscrit dans le concept CI/CD.

Conclusion

Évidemment, la distribution ainsi compilée ne doit pas être immédiatement envoyée en production. Vous devez comprendre que s’il existe un réel besoin de développer et de soutenir votre distribution, vous devez alors y investir de l’argent et du temps.

Cependant, en combinaison avec la bonne approche et une équipe professionnelle, il est tout à fait possible de se passer de solutions commerciales.

Il est important de noter que le projet Bigtop lui-même a besoin d’être développé et ne semble pas être activement développé aujourd’hui. La perspective d'y apparaître Hadoop 3 n'est pas non plus claire. À propos, si vous avez réellement besoin de construire Hadoop 3, vous pouvez consulter fourchette d'Arenadata, dans lequel, en plus du standard
Il existe un certain nombre de composants supplémentaires (Ranger, Knox, NiFi).

Quant à Rostelecom, Bigtop est pour nous l'une des options envisagées aujourd'hui. Que nous le choisissions ou non, le temps nous le dira.

Appendice

Pour inclure un nouveau composant dans l'assembly, vous devez ajouter sa description à bigtop.bom et ./bigtop-packages. Vous pouvez essayer de le faire par analogie avec les composants existants. Essayez de comprendre. Ce n'est pas aussi difficile qu'il y paraît à première vue.

Qu'en penses-tu? Nous serons ravis de connaître votre avis dans les commentaires et merci de votre attention !

L'article a été préparé par l'équipe de gestion des données de Rostelecom

Source: habr.com