Valószínűleg nem titok, hogy a tavalyi év a nagy változások éve volt az Apache Hadoop számára. Tavaly a Cloudera és a Hortonworks egyesült (lényegében az utóbbi felvásárlása), a Mapr pedig komoly anyagi gondok miatt a Hewlett Packardnak adták el. És ha néhány évvel korábban a helyszíni telepítések esetében gyakran a Cloudera és a Hortonworks között kellett választani, ma sajnos nincs lehetőségünk erre. További meglepetés volt, hogy a Cloudera ez év februárjában bejelentette, hogy leállítja terjesztésének bináris összeállításainak nyilvános adattárba való kiadását, és ezek már csak fizetős előfizetéssel érhetők el. Természetesen továbbra is le lehet tölteni a CDH és HDP 2019 vége előtt megjelent legfrissebb verzióit, amelyek támogatása egy-két évig várható. De mi a teendő ezután? Azok számára, akik korábban fizettek előfizetésért, semmi sem változott. Azok számára pedig, akik nem szeretnének a disztribúció fizetős verziójára váltani, ugyanakkor szeretnének megkapni a fürtkomponensek legújabb verzióit, valamint a javításokat és egyéb frissítéseket, elkészítettük ezt a cikket. Ebben megvizsgáljuk a helyzetből való kilábalás lehetséges lehetőségeit.
A cikk inkább áttekintés. Nem fogja tartalmazni a disztribúciók összehasonlítását és részletes elemzését, és nem lesz recept a telepítésükhöz és konfigurálásukhoz. Mi fog történni? Röviden szót ejtünk egy olyan disztribúcióról, mint az Arenadata Hadoop, amely ma már igen ritka elérhetősége miatt joggal érdemli meg figyelmünket. És akkor beszélünk a Vanilla Hadoopról, főleg arról, hogyan lehet „főzni” Apache Bigtop segítségével. Kész? Akkor üdv a macskában.
Arenadata Hadoop
Ez egy teljesen új és egyelőre kevéssé ismert hazai fejlesztésű disztribúciós készlet. Sajnos jelenleg a Habrén van csak .
További információ a hivatalos oldalon található projekt. A disztribúció legújabb verziói a Hadoop 3.1.2-n alapulnak a 3-as verzióhoz, és a 2.8.5-ös verzión a 2-es verzióhoz.
Az útitervvel kapcsolatos információk megtalálhatók .
Arenada Cluster Manager felület
Az Arenadata alapterméke , amely különféle vállalati szoftvermegoldások telepítésére, konfigurálására és monitorozására szolgál. Az ADCM ingyenesen terjeszthető, és funkcionalitása kibővült csomagok hozzáadásával, amelyek egy lehetséges játékkönyv készlet. A csomagok két típusra oszthatók: vállalati és közösségi. Ez utóbbiak ingyenesen letölthetők az Arenadata weboldaláról. Lehetőség van saját csomag fejlesztésére és az ADCM-hez való csatlakoztatására is.
A Hadoop 3 telepítéséhez és kezeléséhez a csomag közösségi verziója elérhető az ADCM-mel együtt, de a Hadoop 2 esetében csak alternatívaként. Ami a csomagokat tartalmazó tárolókat illeti, ezek nyilvánosak, a klaszter összes összetevőjéhez a szokásos módon letölthetők és telepíthetők. Összességében az elosztás nagyon érdekesnek tűnik. Biztos vagyok benne, hogy lesznek olyanok, akik hozzászoktak az olyan megoldásokhoz, mint a Cloudera Manager és az Ambari, és akik szeretni fogják magát az ADCM-et. Egyesek számára ez is hatalmas plusz lesz, hogy a terjesztés az import helyettesítésére.
Ha a hátrányokról beszélünk, akkor ugyanazok lesznek, mint az összes többi Hadoop disztribúció esetében. Ugyanis:
- Az úgynevezett „szállítói zárolás”. A Cloudera és a Hortonworks példáit felhasználva már felismertük, hogy mindig fennáll a veszélye a vállalati politika megváltoztatásának.
- Jelentős lemaradás az Apache-hoz képest.
Vanília Hadoop
Mint tudják, a Hadoop nem egy monolitikus termék, hanem valójában szolgáltatások egész galaxisa a HDFS elosztott fájlrendszere körül. Kevés embernek elég egy fájlfürt. Egyeseknek Hive kell, másoknak Presto, és ott van a HBase és a Phoenix; egyre gyakrabban használják a Sparkot. A hangszereléshez és az adatbetöltéshez néha megtalálható az Oozie, a Sqoop és a Flume. És ha felmerül a biztonság kérdése, akkor azonnal a Kerberos és a Ranger együttes jut eszébe.
A Hadoop-összetevők bináris verziói elérhetők az egyes ökoszisztéma-projektek webhelyén tarballok formájában. Letöltheti őket és megkezdheti a telepítést, de egy feltétellel: amellett, hogy önállóan összeállítja a csomagokat „nyers” binárisokból, amit valószínűleg meg is szeretne tenni, nem lesz biztos abban, hogy a komponensek letöltött verziói kompatibilisek az egyes komponensekkel. Egyéb. Az előnyben részesített lehetőség az Apache Bigtop használatával történő építés. A Bigtop lehetővé teszi az Apache maven tárolókból való építkezést, tesztek futtatását és csomagok készítését. Ami azonban nagyon fontos számunkra, a Bigtop összeállítja azokat az alkatrészeket, amelyek kompatibilisek lesznek egymással. Az alábbiakban részletesebben szólunk róla.
Apache Bigtop
Az Apache Bigtop egy olyan eszköz, amely számos eszköz építésére, csomagolására és tesztelésére szolgál
nyílt forráskódú projektek, mint például a Hadoop és a Greenplum. A Bigtopnak bőven van
kiadja. A cikk írásakor a legújabb stabil kiadás az 1.4-es verzió volt,
masterben pedig 1.5 volt. A kiadások különböző verziói különböző verziókat használnak
alkatrészek. Például az 1.4-es Hadoop alapösszetevőinek 2.8.5-ös verziója van, és a mester
2.10.0. A támogatott komponensek összetétele is változik. Valami elavult és
a megújulhatatlan elmúlik, és helyette jön valami új, igényesebb, ill
ez nem feltétlenül magától az Apache családtól származik.
Ezen kívül a Bigtop sok .
Amikor elkezdtük ismerkedni a Bigtoppal, először is meglepődtünk a többi Apache projekthez képest szerény elterjedtségén és népszerűségén, valamint egy nagyon kis közösségén. Ebből az következik, hogy minimális információ van a termékről, és a fórumokon, levelezőlistákon felmerült problémákra keresve lehet, hogy egyáltalán nem hoznak semmit. Eleinte nehéz feladatnak bizonyult számunkra a disztribúció teljes összeszerelése magának az eszköznek a tulajdonságai miatt, de erről majd egy kicsit később.
Mint egy kedvcsináló, azoknak, akik egy időben érdeklődtek a Linux-univerzum olyan projektjei iránt, mint a Gentoo és az LFS, nosztalgikusan kellemesnek találhatják ezzel a dologgal dolgozni, és emlékezhetnek azokra az „epikus” időkre, amikor mi magunk is kerestünk (vagy akár írtunk). újraépíti és rendszeresen átépíti a Mozillát új javításokkal.
A Bigtop nagy előnye az alapját képező eszközök nyitottsága és sokoldalúsága. A Gradle és az Apache Maven alapja. A Gradle meglehetősen jól ismert, mint a Google által az Android felépítéséhez használt eszköz. Rugalmas, és ahogy mondani szokták, „harcban tesztelt”. A Maven egy szabványos eszköz az Apache projektek építéséhez, és mivel a legtöbb terméke a Mavenen keresztül jelenik meg, itt sem lehetne nélküle. Érdemes figyelni a POM-ra (projektobjektum modell) - az „alapvető” xml fájlra, amely mindent leír, ami ahhoz szükséges, hogy a Maven működjön a projekttel, és amely köré minden munka épül. Pontosan at
a Maven egyes részei, és vannak olyan akadályok, amelyekkel az első Bigtop-felhasználók általában találkoznak.
Gyakorlat
Szóval hol érdemes kezdeni? Lépjen a letöltési oldalra, és töltse le a legújabb stabil verziót archívumként. A Bigtop által gyűjtött bináris tárgyakat is megtalálhatja ott. Egyébként a közös csomagkezelők közül a YUM és az APT támogatott.
Alternatív megoldásként letöltheti a legújabb stabil kiadást közvetlenül a webhelyről
github:
$ git clone --branch branch-1.4 https://github.com/apache/bigtop.gitKlónozás „nagytopban”…
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), готово.Az eredményül kapott ./bigtop könyvtár valahogy így néz ki:
./bigtop-bigpetstore — bemutató alkalmazások, szintetikus példák
./bigtop-ci - CI szerszámok, jenkinek
./bigtop-data-generators — adatgenerálás, szintetika, füstvizsgálatokhoz stb.
./bigtop-deploy - telepítési eszközök
./bigtop-packages — konfigurációk, szkriptek, javítások az összeszereléshez, az eszköz fő része
./bigtop-test-framework — tesztelési keretrendszer
./bigtop-tests — maguk a vizsgálatok, a terhelés és a füst
./bigtop_toolchain — összeszerelési környezet, a környezet előkészítése a szerszám működéséhez
./build - munkakönyvtár létrehozása
./dl — a letöltött források könyvtára
./docker — docker képekbe építés, tesztelés
./gradle - gradle konfig
./output – a könyvtár, ahová a build műtermékek kerülnek
./provisioner — tartalékolás
A legérdekesebb számunkra ebben a szakaszban a fő konfiguráció ./bigtop/bigtop.bom, amelyben az összes támogatott összetevőt láthatjuk verziókkal. Itt adhatjuk meg a termék más verzióját (ha hirtelen meg akarjuk próbálni építeni), vagy build verziót (ha például egy jelentős javítást adtunk hozzá).
Az alkönyvtár is nagy érdeklődésre tart számot ./bigtop/bigtop-packages, amely közvetlenül kapcsolódik az alkatrészek és csomagok összeszerelésének folyamatához.
Szóval, letöltöttük az archívumot, kicsomagoltuk vagy klónt készítettünk a githubból, elkezdhetjük az építést?
Nem, először készítsük elő a környezetet.
A környezet előkészítése
És itt kell egy kis visszavonulás. Szinte bármilyen többé-kevésbé összetett termék felépítéséhez szükség van egy bizonyos környezetre - esetünkben ez a JDK, ugyanazok a megosztott könyvtárak, fejlécfájlok stb., eszközök, például ant, ivy2 és még sok más. A Bigtop számára szükséges környezet létrehozásának egyik lehetősége a szükséges összetevők telepítése a build gazdagépen. Lehet, hogy tévedek a kronológiában, de úgy tűnik, hogy az 1.0-s verziónál lehetőség volt előre konfigurált és elérhető Docker-képek beépítésére is, ami itt található.
Ami a környezet előkészítését illeti, ehhez van egy asszisztens - Báb.
A gyökérkönyvtárból futtatva a következő parancsokat használhatja
eszköz, ./bigtop:
./gradlew toolchain
./gradlew toolchain-devtools
./gradlew toolchain-puppetmodules
Vagy közvetlenül a bábon keresztül:
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"Sajnos már ebben a szakaszban is felmerülhetnek nehézségek. Az általános tanács itt az, hogy használjon támogatott disztribúciót, naprakész a build gazdagépen, vagy próbálja ki a docker útvonalat.
gyülekezés
Mit próbálhatunk összegyűjteni? Erre a kérdésre a választ a parancs kimenete adja meg
./gradlew tasks
A Csomagfeladatok részben számos olyan termék található, amelyek a Bigtop végső termékei.
Azonosíthatóak az -rpm vagy -pkg-ind utótaggal (épület esetén
dockerben). Esetünkben a legérdekesebb a Hadoop.
Próbáljunk meg a build szerverünk környezetében építeni:
./gradlew hadoop-rpmA Bigtop maga letölti az adott komponenshez szükséges forrásokat, és megkezdi az összeszerelést. Így az eszköz működése Maven tárolóktól és egyéb forrásoktól függ, azaz internet hozzáférést igényel.
Működés közben szabványos kimenet jön létre. Néha ez és a hibaüzenetek segíthetnek megérteni, mi hibázott. És néha további információkra van szükség. Ebben az esetben érdemes érveket hozzáadni --info vagy --debug, és hasznos is lehet –stacktrace. Van egy kényelmes módja egy adatkészlet létrehozásának a levelezőlisták későbbi eléréséhez, a kulcs --scan.
Segítségével a bigtop összegyűjti az összes információt, és gradle-be helyezi, majd hivatkozást ad,
amelyet követve egy hozzáértő személy képes lesz megérteni, miért nem sikerült a szerelés.
Kérjük, vegye figyelembe, hogy ez a lehetőség olyan információkat jeleníthet meg, amelyeket nem szeretne, például felhasználóneveket, csomópontokat, környezeti változókat stb., ezért legyen óvatos.
A hibák gyakran annak a következményei, hogy az összeszereléshez szükséges alkatrészeket nem lehet beszerezni. Általában úgy javíthatja ki a problémát, hogy létrehoz egy javítást, amely javít valamit a forrásokban, például a források gyökérkönyvtárában lévő pom.xml-ben található címeket. Ez úgy történik, hogy létrehozza és a megfelelő könyvtárba helyezi ./bigtop/bigtop-packages/src/common/oozie/ foltot például a formában 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>
Valószínűleg a cikk elolvasásakor nem kell magának elvégeznie a fenti javítást.
Amikor bármilyen javítást és változtatást vezet be az összeállítási mechanizmuson, előfordulhat, hogy „vissza kell állítania” az összeállítást a cleanup paranccsal:
./gradlew hadoop-clean
> Task :hadoop_vardefines
> Task :hadoop-clean
BUILD SUCCESSFUL in 5s
2 actionable tasks: 2 executedEz a művelet visszaállítja az összetevő összeállításának összes módosítását, majd az összeszerelést újra végrehajtja. Ezúttal megpróbáljuk felépíteni a projektet docker image-ben:
./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 executedA felépítés CentOS alatt történt, de Ubuntu alatt is meg lehet csinálni:
./gradlew -POS=ubuntu-16.04 -Pprefix=1.2.1 hadoop-pkg-indA különféle Linux-disztribúciók csomagjainak összeállítása mellett az eszköz létrehozhat egy lerakat is lefordított csomagokkal, például:
./gradlew yumEmlékezhet a füsttesztekre és a Dockerben történő telepítésre is.
Hozzon létre három csomópontból álló klasztert:
./gradlew -Pnum_instances=3 docker-provisionerFuttasson füstteszteket egy három csomópontból álló klaszterben:
./gradlew -Pnum_instances=3 -Prun_smoke_tests docker-provisionerKlaszter törlése:
./gradlew docker-provisioner-destroyParancsok lekérése a belső docker-tárolók csatlakoztatásához:
./gradlew docker-provisioner-sshÁllapot megjelenítése:
./gradlew docker-provisioner-statusA telepítési feladatokról bővebben a dokumentációban olvashat.
Ha már tesztekről beszélünk, akkor elég nagy számban vannak, főleg füst és integráció. Elemzésük túlmutat e cikk keretein. Csak annyit mondok, hogy az elosztókészlet összeállítása nem olyan nehéz feladat, mint amilyennek első pillantásra tűnhet. Sikerült összeállítani és tesztelni az összes komponenst, amelyet termelésünkben használunk, és nem volt gondunk a telepítéssel és a tesztkörnyezetben végzett alapvető műveletekkel sem.
A Bigtopban meglévő komponensek mellé bármi mást is hozzáadhat, akár saját szoftverfejlesztést is. Mindez tökéletesen automatizált, és beleillik a CI/CD koncepcióba.
Következtetés
Nyilvánvalóan az így összeállított disztribúciót nem szabad azonnal gyártásba küldeni. Meg kell értened, hogy ha valóban szükség van a disztribúció felépítésére és támogatására, akkor ebbe pénzt és időt kell fektetni.
A megfelelő megközelítéssel és egy professzionális csapattal kombinálva azonban teljesen megoldható kereskedelmi megoldások nélkül.
Fontos megjegyezni, hogy maga a Bigtop projekt fejlesztésre szorul, és úgy tűnik, hogy jelenleg nem fejlesztik aktívan. A Hadoop 3 megjelenésének esélye sem tisztázott. Egyébként, ha valóban szüksége van a Hadoop 3 megépítésére, akkor megnézheti az Arenadata-ból, melyben a szabvány mellett
Számos további komponens található (Ranger, Knox, NiFi).
Ami a Rostelecomot illeti, számunkra a Bigtop az egyik ma mérlegelt lehetőség. Hogy választjuk-e vagy sem, az idő eldönti.
Függelék
Ha új komponenst szeretne beépíteni az összeállításba, hozzá kell adnia a leírását a bigtop.bom és a ./bigtop-packages fájlokhoz. Megpróbálhatja ezt a meglévő komponensekkel analóg módon megtenni. Próbáld meg kitalálni. Nem olyan nehéz, mint amilyennek első pillantásra tűnik.
Mit gondolsz? Örömmel látjuk véleményét a megjegyzésekben, és köszönjük a figyelmet!
A cikket a Rostelecom adatkezelő csapata készítette
Forrás: will.com