Apache Bigtop dhe zgjedhja e shpërndarjes Hadoop sot

Ndoshta, askush nuk e di se viti i kaluar ishte një vit me ndryshime të mëdha për Apache Hadoop. Vitin e kaluar u realizua bashkimi i Cloudera me Hortonworks (në fakt, kjo ishte një absorbim i fundit), dhe Mapr, për shkak të problemeve të rënda financiare, u shit Hewlett Packard. Ndërsa disa vite më parë, në rastin e instalimeve on-premises, shpesh zgjedhja bëhej midis Cloudera dhe Hortonworks, sot fatkeqësisht nuk e kemi më këtë zgjedhje. Një surprizë ishte gjithashtu fakti se Cloudera që nga shkurt i këtij viti shpalli ndalimin e lëshimit të ndërtimeve binare të shpërndarjes së saj në depo publike, dhe tani ato janë të disponueshme vetëm me një abonim të paguar. Sigurisht, mundësia për të shkarkuar versionet e fundit të CDH dhe HDP, të lëshuara deri në fund të vitit 2019, ekziston ende, dhe mbështetje për to është parashikuar për një deri në dy vjet. Por çfarë do të bëjmë tani? Për ata që më parë paguanin për një abonim, nuk ka asnjë ndryshim. Për ata që nuk duan të kalojnë në versionin e paguar të shpërndarjes, por gjithsesi dëshirojnë të kenë mundësinë për të marrë versione të freskëta të komponenteve të klasterit, si dhe patches dhe përditësime të tjera, ne e përgatitëm këtë artikull. Në të, do të shqyrtojmë mundësitë për të dalë nga kjo situatë.

Artikulli është më shumë një përmbledhje. Nuk do të ketë krahasime të shpërndarjeve dhe analizave të tyre të hollësishme, as nuk do të ketë receta për instalimin dhe konfigurimin e tyre. Çfarë do të ketë atëherë? Ne do të flasim në mënyrë të shkurtër për shpërndarjen Arenadata Hadoop, e cila me të drejtë e meriton vëmendjen tonë për shkak të disponueshmërisë së saj, e cila sot është një raritet i madh. Më pas do të flasim për Vanilla Hadoop, kryesisht për mënyrën se si mund ta

Arenadata Hadoop

Ky është një shpërndarje krejtësisht e re dhe, për momentin, pak e njohur me origjinë vendase. Fatkeqësisht, në këtë moment, në Habrë për të ka vetëm artikull.

Më shumë informacion mund të gjendet në faqen zyrtare të internetit të projektit. Versionet e fundit të shpërndarjes janë të bazuara në Hadoop 3.1.2 për versionin 3 dhe 2.8.5 për versionin 2.

Informacioni mbi roadmap mund të gjendet këtu.

Ndërfaqja e Arenadata Cluster Manager

Produkti kyç i Arenadata është Arenadata Cluster Manager (ADCM), i cili përdor për instalimin, konfigurimin dhe monitorimin e zgjidhjeve të ndryshme softuerike të kompanisë. ADCM shpërndahet falas, dhe funksionaliteti i tij zgjeron me anë të shtimit të bundeve, të cilat përbëjnë një grup ansible-playbooks. Bundet ndahen në dy lloje: enterprise dhe community. Të fundit janë të disponueshëm për shkarkim falas nga faqja Arenadata. Ka gjithashtu mundësinë për të zhvilluar një bundle të vetin dhe ta lidhi atë me ADCM.

Për deploimin dhe menaxhimin e Hadoop 3 ofrohet një version community i bundle-it në lidhje me ADCM, ndërsa për hadoop 2 ka vetëm Apache Ambari si një alternativë. Sa i përket depozitave me paketa, ato janë të hapura për akses publik, mund të shkarkohen dhe instalohen në mënyrë të zakonshme për të gjithë komponentët e klasterit. Në përgjithësi, distribucioni duket mjaft interesant. Jam i sigurt se do të ketë ata që janë mësuar me zgjidhje si Cloudera Manager dhe Ambari, dhe që do ta pëlqejnë ADCM. Për disa, do të jetë një avantazh i madh gjithashtu fakti se distributi ndodhet në regjistrin e softuerit për zëvendësimin e importeve.

Nëse flasim për disavantazhet, ato do të jenë të njëjtat si për të gjithë distributet e tjera të Hadoop. Në veçanti:

• Kjo është e ashtuquajtura «vendor lock-in». Me anë të Cloudera dhe Hortonworks, ne tashmë kemi kuptuar se gjithmonë ekziston rreziku i ndryshimit të politikave të kompanisë.
• Dohatisa prapa e konsiderueshme nga upstream Apache.

Vanilla Hadoop

Siç e dini, Hadoop – nuk është një produkt monolitik, por, në thelb, një sërë shërbimesh rreth sistemit të tij të skedarëve të shpërndarë HDFS. Pak njerëz do të jenë të kënaquar vetëm me një klaster skedarësh. Disa kanë nevojë për Hive, disa për Presto, dhe gjithashtu ka HBase dhe Phoenix, gjithnjë e më shumë përdoret Spark. Për orkestrimin dhe ngarkimin e të dhënave, ndonjëherë hasen Oozie, Sqoop dhe Flume. Dhe nëse ngrihet çështja e sigurimit, menjëherë kujtohet Kerberos në lidhje me Ranger.

Versionet binar të komponenteve Hadoop janë të disponueshme në faqen e çdo projekti të ekosistemit në formën e tarballs. Ato mund të shkarkohen dhe të filloni instalimin, por me një kush: përveç ndërtimit të paketave nga 'kanalet' e papërpunuara, që dyshojmë se do të dëshironit të realizoni, nuk do të keni asnjë siguri për përputhshmërinë e versioneve të shkarkuara të komponenteve me njëri-tjetrin. Një opsion më i preferuar është ndërtimi me Apache Bigtop. Bigtop do t'ju lejojë të bëni ndërtimin nga depot maven të Apache, të kryeni teste dhe të krijoni paketa. Por, ajo që është shumë e rëndësishme për ne, Bigtop do të krijojë ato versione të komponenteve që do të jenë të përputhshme me njëri-tjetrin. Pikat më të detajuara për të do i trajtojmë më poshtë.

Apache Bigtop

Apache Bigtop është një mjet për ndërtimin, paketimin dhe testimin e një sërë
projekteve open source, të tilla si Hadoop dhe Greenplum. Bigtop ka një shumëllojshmëri
publikimesh. Në momentin e shkrimit të artikullit, publikimi më i fundit stabil ishte versioni 1.4,
ndërsa në master ndodhej 1.5. Në versione të ndryshme publikimesh, përdoren versione të ndryshme
të komponentëve. Për shembull, për 1.4 komponentët thelbësorë të Hadoop kanë versionin 2.8.5, ndërsa në master
2.10.0. Ndryshon po ashtu struktura e komponentëve të mbështetur. Diçka e vjetruar dhe
e papërditësuar largohet, ndërsa në vend të saj vjen diçka e re, më e kërkuar, dhe
nuk është domosdoshmërisht diçka nga familja e Apache vetë.

Për më tepër, Bigtop ka një shumëllojshmëri forkesh.

Kur filluam të njohim Bigtop, na surprizoi së pari përhapja e tij modeste, krahasuar me projektet e tjera Apache, dhe fama e tij mjaft e vogël, si dhe një komunitet shumë të vogël. Kjo nënkupton se informacioni mbi produktin është minimal, dhe kërkimi për zgjidhje të problemeve të paraqitura në forume dhe lista mund të mos japë asgjë. Në fillim, për ne ishte një detyrë e vështirë të realizonim një ndërtim të plotë të distribucionit për shkak të veçorive të vetë mjetit, por për këtë do të flasim pak më vonë.

Si një teaser - atyre që në kohën e tyre i pëlqenin projekte si Gentoo dhe LFS në universin Linux, ndoshta do t'i duket nostalgjikisht këndshëm të punojnë me këtë gjë dhe të kujtojnë ato 'epike' kohë kur ne vetë kërkonim (apo madje shkruanim) ebuilds dhe rregullisht rindërtonim me patch të rinj Mozilla.

Një avantazh i madh i Bigtop është hapësira dhe universialiteti i mjeteve mbi të cilat është ndërtuar. Në themel të tij qëndrojnë Gradle dhe Apache Maven. Gradle është mjaft i njohur si një mjet që Google përdor për të ndërtuar Android. Ai është fleksibël dhe, siç thonë, "i testuar në luftë". Maven është mjeti standard për ndërtimin e projekteve në vetë Apache, dhe, pasi shumica e produkteve të tij lëshohen përmes Maven, gjithashtu është e domosdoshme. Duhet të vihet re POM (modeli i objektit të projektit) – një skedar xml "themelor" që përshkruan gjithçka të nevojshme për punën e Maven me projektin tuaj, rreth të cilit ndërtohet gjithçka.
Në pjesën e Maven shfaqen disa pengesa me të cilat zakonisht përballen ata që e përdorin për herë të parë Bigtop.

Praktika

Pra, nga nga e si duhet të filloni? Shkoni në faqen e shkarkimit dhe shkarkoni versionin e fundit stabil si një arkiv. Aty gjithashtu mund të gjeni dhe artefaktet binarë të ndërtuara nga Bigtop. Në fakt, nga menaxherët e zakonshëm të paketave mbështeten YUM dhe APT.

Si një mënyrë alternative, mund të shkarkoni versionin e fundit stabil direkte nga
github:

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

Klonimi në "bigtop"...

remote: Duke numëruar objekte: 46, e përfunduar.
remote: Duke numëruar objekte: 100% (46/46), e përfunduar.
remote: Duke kompresuar objekte: 100% (41/41), e përfunduar.
remote: Totali 40217 (delta 14), përshtatur 10 (delta 1), përdorur sërish 40171
Marrja e objekteve: 100% (40217/40217), 43.54 MiB | 1.05 MiB/s, përfunduar.
Përcaktimi i ndryshimeve: 100% (20503/20503), përfunduar.
Përditësimi i skedarëve: 100% (1998/1998), përfunduar.

Katalogu i krijuar ./bigtop duket rreth kësaj:

./bigtop-bigpetstore — aplikacione demonstrative, shembuj sintetikë
./bigtop-ci — mjetet CI, jenkins
./bigtop-data-generators — gjenerimi i të dhënave, sintetik, për testet smoke etj.
./bigtop-deploy — mjetet për përdorimin e aplikacioneve
./bigtop-packages — konfigurimet, skenat, patches për ndërtim, pjesa kryesore e mjetit
./bigtop-test-framework — korniza e testimeve
./bigtop-tests — testimet vetë, testet e ngarkesës dhe smoke
./bigtop_toolchain — mjedisi i ndërtimit, përgatitja e mjedisit për veprimin e mjeteve
./build — katalogu i punës për ndërtimin
./dl — katalogu për burimet e shkarkuara
./docker — ndërtimi në imazhe docker, testimi
./gradle — konfigurimi i gradle
./output – katalogu në të cilin shkojnë artefaktet e ndërtimit
./provisioner — provizionimi

Ajo që është më interesante në këtë fazë për ne është konfigurimi kryesor ./bigtop/bigtop.bom, ku shohim të gjitha komponentët e mbështetur me versionet. Këtu mund të specifikojmë një version tjetër të produktit (nëse ndonjëherë duam ta provokojmë të ndërtojmë atë) ose versionin e ndërtimit (nëse, për shembull, kemi shtuar një patch të rëndësishëm).

Gjithashtu, nënkatalogu .\/bigtop\/bigtop-packages, i cili ka të bëjë drejtpërdrejt me procesin e ndërtimit të komponentëve dhe paketave me to.

Pra, ne e kemi shkarkuar arkivin, e kemi shpërndarë atë ose kemi bërë një klon nga github, a mund të fillojmë ndërtimin?

Jo, së pari duhet të përgatitim mjedisin.

Përgatitja e mjedisit

Dhe këtu na nevojitet një devijim i vogël. Për të ndërtuar pothuajse çdo produkt më ose më pak të ndërlikuar, është i nevojshëm një mjedis i caktuar - në rastin tonë është JDK, ato biblioteka të ndara, skedarët e titullit, etj., mjete si ant, ivy2 dhe shumë të tjera. Një nga mënyrat për të marrë mjedisin e nevojshëm për Bigtop është instalimi i komponentëve të nevojshëm në hostin e ndërtimit. Mund të kem gabime në kronologji, por ndoshta nga versioni 1.0 gjithashtu u shfaq një mundësi ndërtimi në imazhet docker të parakonfiguruara dhe të disponueshme, ato mund të shqyrtohen këtu.

Sa i përket përgatitjes së mjedisit, për këtë ka një ndihmës - Puppet.

Mund të përdorni komandat e mëposhtme, nisja bëhet nga katalogu rrënjësor
i mjetit, .\/bigtop:

.\/gradlew toolchain\n.\/gradlew toolchain-devtools\n.\/gradlew toolchain-puppetmodules

Ose direkt përmes puppet:

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

Fatkeqësisht, tashmë në këtë fazë mund të ketë vështirësi. Këshilla e përgjithshme këtu është - përdorni një distribucion të mbështetur, në gjendje aktuale në hostin e ndërtimit ose provoni rrugën me docker.

Ndërtimi

Çfarë mund të përpiqemi të ndërtojmë? Përgjigjen për këtë pyetje do ta japë dalja e komandës

.\/gradlew tasks

Në seksionin e Paketave ka një sërë produktesh që janë artefakte përfundimtare të Bigtop.
Ato mund të identifikohen nga sufiksi -rpm ose -pkg-ind (në rastin e ndërtimit
në docker). Në rastin tonë, Hadoop është më interesanti.

Le të përpiqemi të kryejmë ndërtimin në mjedisin e serverit tonë të ndërtimit:

.\/gradlew hadoop-rpm

Bigtop do të shkarkojë vetë burimet e nevojshme, të nevojshme për komponentin specifik, dhe do të fillojë ndërtimin. Kështu, funksionimi i mjetit është i lidhur me depot Maven dhe burime të tjera, pra, i nevojitet qasja në Internet.

Në procesin e punës formohet një dalje standarde. Ndonjëherë nga ajo dhe mesazhet e gabimeve mund të kuptohet se çfarë ka shkuar keq. Ndërsa herë të tjera kërkohet të merret më shumë informacion. Në këtë rast është mirë të shtohesh argumente --info ose --debug, si dhe mund të jetë e dobishme –stacktrace. Ka një mënyrë të përshtatshme për të formuar një grup të dhënash për një referencë të mëvonshme në listat e dërgimit, çelësi --scan.

Me ndihmën e tij, bigtop do të mbledhë të gjithë informacionin dhe do ta nxjerrë në gradle, pas së cilës do të japë një lidhje,
nëpërmjet të cilës një person kompetent do të jetë në gjendje të kuptojë se përse ndodhi dështimi i ndërtimit.
Duhet të keni parasysh se kjo opsion mund ta bëjë publike informacionin që nuk dëshironi të jetë i aksesueshëm, për shembull, emrat e përdoruesve, nodet, variablat e mjedisit, etj., kështu që jini të kujdesshëm.

Shpesh gabimet janë pasojë e pamundësisë për të marrë disa komponente të nevojshme për ndërtim. Në përgjithësi, problemi mund të riparohen duke krijuar një patch për të korrigjuar diçka në burim, për shembull, adresën në pom.xml në katalogun rrënjor të burimeve. Kjo bëhet duke krijuar dhe vendosur atë në katalogun përkatës .\/bigtop\/bigtop-packages\/src\/common\/oozie\/ patch, për shembull, në formën 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>

Me shumë të ngjarë, në momentin kur po e lexoni këtë artikull, disa nga riparimet e përmendura më lart nuk do t'ju nevojitet t'i bëni vetë.

Në implementimin e ndonjë patch-e dhe rregullime në mekanizmin e ndërtimit mund të nevojitet të "resetoni" ndërtimin përmes komandës së pastrimit:

.\/gradlew hadoop-clean
> Detyra :hadoop_vardefines
> Detyra :hadoop-clean
KONSTRUKT I SUKSESËSHËM në 5s
2 detyra në veprim: 2 ekzekutuar

Kjo operacion do të rikthejë të gjitha ndryshimet për ndërtimin e këtij komponenti, pas së cilës ndërtimi do të kryhet përsëri. Këtë herë do të provojmë të ndërtomë projektin në një imazh docker:

.\/gradlew -POS=centos-7 -Pprefix=1.2.1 hadoop-pkg-ind
> Task :hadoop-pkg-ind
Ndërtohet hadoop-pkg 1.2.1 në centos-7 në 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
....
shumë dalje
....
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-2.8.5-1.el7.x86_64.rpm
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-2.8.5-1.el7.x86_64.rpm
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-yarn-2.8.5-1.el7.x86_64.rpm
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-mapreduce-2.8.5-1.el7.x86_64.rpm
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-namenode-2.8.5-1.el7.x86_64.rpm
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-secondarynamenode-2.8.5-
1.el7.x86_64.rpm
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-zkfc-2.8.5-1.el7.x86_64.rpm
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-journalnode-2.8.5-
1.el7.x86_64.rpm
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-datanode-2.8.5-1.el7.x86_64.rpm
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-httpfs-2.8.5-1.el7.x86_64.rpm
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-yarn-resourcemanager-2.8.5-
1.el7.x86_64.rpm
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-yarn-nodemanager-2.8.5-
1.el7.x86_64.rpm
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-yarn-proxyserver-2.8.5-
1.el7.x86_64.rpm
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-yarn-timelineserver-2.8.5-
1.el7.x86_64.rpm
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-mapreduce-historyserver-2.8.5-
1.el7.x86_64.rpm
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-client-2.8.5-1.el7.x86_64.rpm
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-conf-pseudo-2.8.5-1.el7.x86_64.rpm
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-doc-2.8.5-1.el7.x86_64.rpm
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-libhdfs-2.8.5-1.el7.x86_64.rpm
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-libhdfs-devel-2.8.5-1.el7.x86_64.rpm
Shkruar: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-fuse-2.8.5-1.el7.x86_64.rpm
Shkruar: \/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
Duke (%clean): \/bin\/sh -e \/var\/tmp\/rpm-tmp.uQ2FCn
+ exit 0
+ umask 022
Duke (--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] Duke \/bigtop\/build\/hadoop\/.rpm
:hadoop-rpm (Thread[Task worker for ':',5,main]) përfundoi. Zgjati 38 minuta 1.151 sekonda.
:hadoop-pkg (Thread[Task worker for ':',5,main]) filloi.
> Task :hadoop-pkg
Task ':hadoop-pkg' nuk është në përditësim pasi:
Task nuk ka shpallur ndonjë dalje megjithëse ka ekzekutuar veprime.
:hadoop-pkg (Thread[Task worker for ':',5,main]) përfundoi. Zgjati 0.0 sekonda.
NDERTIMI SUKSES MË 40m 37s
6 detyra të veprueshme: 6 të ekzekutuara
+ 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
Gabim: Nuk ka një kontejner të tillë:
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
NDERTIMI SUKSES MË 41m 24s
1 detyr e veprueshme: 1 e ekzekutuar

Këtu është konstrukti për CentOS, por gjithashtu mund të ekzekutohet edhe për Ubuntu:

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

Përveç ndërtimit të pakove për shpërndarje të ndryshme Linux, ky mjet është në gjendje të krijojë një depotë me paketat e ndërtuara, për shembull:

.\/gradlew yum

Gjithashtu mund të përmendim testet smoke dhe vendosjen në docker.

Krijo një klaster prej tre nodësh:

.\/gradlew -Pnum_instances=3 docker-provisioner

Nis testet smoke në klasterin prej tre nodësh:

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

Çmo klasterin:

.\/gradlew docker-provisioner-destroy

Merr komandat për t'u lidhur brenda kontejnerëve docker:

.\/gradlew docker-provisioner-ssh

Trego gjendjen:

.\/gradlew docker-provisioner-status

Më shumë detaje rreth detyrave të vendosjes mund të lexoni në dokumentacionin.

Nëse flasim për testet, ka një numër të konsiderueshëm të tyre, kryesisht teste smoke dhe integruese. Shkëputja e tyre është jashtë pamjes së kësaj article. Vetëm do të them se ndërtimi i shpërndarjes nuk është aq i vështirë sa mund të duket në shikim të parë. Të gjitha komponentet që përdorim në prodhim arritëm t'i ndërtojmë dhe të kalojmë testet, dhe gjithashtu nuk kemi hasur në probleme me vendosjen e tyre dhe kryerjen e operacioneve bazë në mjedisin e testit.

Përveç komponentëve ekzistues në Bigtop, ka mundësi të shtosh edhe diçka tjetër, madje edhe zhvillime softuerike të tua. Të gjitha këto automatizohen mirë dhe përshtaten në konceptin CI/CD.

Përfundimi

Natyrisht, shpërndarja e ndërtuar në këtë mënyrë nuk duhet menjëherë të dërgohet në prodhim. Duhet kuptuar se nëse ka një nevojë të vërtetë për ndërtimin dhe mbështetje të shpërndarjes suaj, atëherë duhet të investoni financiarisht dhe me kohë.

Megjithatë, në kombinim me qasje të drejtë dhe një ekip profesional, është krejtësisht e mundur të bëhet pa zgjidhje komerciale.

Është e rëndësishme të theksohet se projekti vetë Bigtop ka nevojë për zhvillim dhe, duket se aktualisht nuk ka zhvillim aktiv në të. Gjithashtu nuk është e qartë perspektiva e shfaqjes së Hadoop 3. Për të thënë, nëse keni një nevojë të vërtetë për ndërtimin e Hadoop 3, mund të shikoni tek fork Arenadata, të cilat përveç komponentëve standardë
kanë edhe një sërë komponentësh shtesë (Ranger, Knox, NiFi).

Sa i përket Rostelecom-it, Bigtop është një nga opsionet e shqyrtuara sot. Nëse do të ndalojmë zgjedhjen tonë tek ai apo jo - koha do ta tregojë.

Shtojca

Për ta përfshirë një komponent të ri në ndërtim, duhet të shtoni përshkrimin e tij në bigtop.bom dhe ./bigtop-packages. Mund të provoni ta bëni këtë në mënyrë analogjike me komponentët ekzistues. Provoni të kuptoni. Nuk është aq e vështirë sa duket në radhë të parë.

Çfarë mendoni ju? Do të na kënaqte të shihnim mendimin tuaj në komentet dhe faleminderit për vëmendjen!

Artikulli është përgatitur nga ekipi i menaxhimit të të dhënave të "Rostelecom"

Burimi: habr.com