नमस्कार, हेब्र!

कुछ महीने पहले, मैंने फ्रंट-एंड के लिए डॉकटर रिपोर्ट के साथ फ्रंटेंडकॉन्फ़ 2019 सम्मेलन में बात की थी और उन लोगों के लिए रिपोर्ट का एक छोटा प्रतिलेख बनाना चाहूंगा जो सुनने से अधिक पढ़ना पसंद करते हैं।

मैं आपको सभी वेब डेवलपर्स को कैट करने के लिए आमंत्रित करता हूं, खासकर फ्रंट-एंड।

सामग्री

सामने के छोर के लिए डॉकटर। भाग 1. क्यों?
सामने के छोर के लिए डॉकटर। भाग 2. आप क्या हैं?
सामने के छोर के लिए डॉकटर। भाग 3. कुछ व्यंजनों

डॉकिंग पर चढ़ना

डॉकर एक नया उपकरण नहीं है, इसे पहली बार मार्च 2013 में वापस प्रकाशित किया गया था और तब से इसकी लोकप्रियता बढ़ी है।

यहाँ हम देखते हैं कि Node.js के अनुरोधों की आवृत्ति एक पठार तक पहुँच गई है और कहीं भी नहीं जा रही है, जबकि Docker के लिए अनुरोधों में वृद्धि जारी है।

यह खिलौना RIT ++ 2019 सम्मेलन में DevOps अनुभाग के भाग के रूप में था। और मेरे अनुभव में, एक भी DevOps सम्मेलन डॉकटर के बारे में रिपोर्टों के बिना नहीं जाता है, ठीक उसी तरह जैसे फ्रंट-एंड कॉन्फ्रेंस फ्रेमवर्क की तुलना करने, वेबपैक स्थापित करने और पेशेवर बर्नआउट के बारे में रिपोर्ट के बिना नहीं जाते हैं।

हमें सामने वाले पक्ष में भी इस तकनीक के बारे में बात करना शुरू करें।

यह एक वेबमास्टर रोडमैप है । बाईं ओर किसी भी विकास पथ के लिए आवश्यक कौशल हैं। वास्तव में, एक अच्छे वेब डेवलपर की कल्पना करना मुश्किल है जो गिट, एक टर्मिनल या एचटीटीपी को नहीं जानता है।

डॉकर भी यहां मौजूद है, लेकिन जहां DevOps की विकास शाखा के बोल्स में इन्फ्रास्ट्रक्चर में कोड के रूप में है -> कंटेनर ब्लॉक।

लेकिन हम जानते हैं कि डॉकटर विकास का एक बड़ा साधन है, न कि केवल शोषण। और, मेरी राय में, उसके पास किसी भी पथ अनुभाग के लिए आवश्यक होने के कुछ समय बाद और फ्रंट-एंड डेवलपर्स की कई रिक्तियों में अनिवार्य आवश्यकता बनने का हर मौका है।

हम कह सकते हैं कि अब हम डॉकर युग में रहते हैं। इसलिए, यदि आप फ्रंट-एंड डेवलपर हैं और अभी तक उनसे नहीं मिले हैं, तो मैं आपको बताऊंगा कि ऐसा क्यों करना है।

क्यों?

केस 1. बैकएंड उठाएं

पहला और सबसे उपयोगी मामला जिस पर हम विचार कर सकते हैं वह है हमारी आरामदायक मैकबुक पर एपीआई लॉन्च करना। हां, हम अपनी तकनीकों को अच्छी तरह से जानते हैं, लेकिन कुछ तीसरे पक्ष को तैनात करना हमेशा एक आसान परीक्षा नहीं होती है।

हमारी एक परियोजना पर, फ्रंट-एंड डेवलपर को कंप्यूटर पर इस तरह के सेट को स्थापित करने की आवश्यकता थी ताकि एपीआई काम करे:

* go1.11 * MySQL * Redis * Elasticsearch * Capistrano * syslog * PostgreSQL

सौभाग्य से, हमारे पास README फाइलों में परियोजना को तैनात करने के निर्देश थे। वे कुछ इस तरह दिखे:

 1.  GVM (https://github.com/moovweb/gvm) 2. `gvm install go1.11.13 --binary` 3. `gvm use go1.11.13 --default` 4.        golang (`gvm linkthis`) 5.  `gb` `go get github.com/constabulary/gb/...` 6.   `git config --global url."git@git.example.com:".insteadOf "https://git.example.com/"` 7.   `gb vendor restore` 8.   9.   `npm run build` (`npm run build:dev`  ) 10.   `npm start`

और इस तरह:

 ## Elasticsearch 1.    Elasticsearch `brew install elasticsearch` - macOS (   java) 2.   *   https://github.com/imotov/elasticsearch-analysis-morphology       ,   `/usr/local/Cellar/elasticsearch/2.3.3/libexec/bin/plugin install http://dl.bintray.com/content/imotov/elasticsearch-plugins/org/elasticsearch/elasticsearch-analysis-morphology/2.3.3/elasticsearch-analysis-morphology-2.3.3.zip` -  *    `brew services restart elasticsearch` 3.    `rake environment elasticsearch:import:model CLASS='Tag' FORCE=y ` `rake environment elasticsearch:import:model CLASS='Post' FORCE=y`   ,     ## Postgres comments db 1. `psql -U postgres -h localhost` 2. `create database comments_dev;` ## Redis install and start 1. `brew install redis` 2.   `brew services start redis`

आपको क्या लगता है, किसी प्रोजेक्ट को परिनियोजित करने और कार्य करने में नौसिखिया डेवलपर को कितना समय लगा?

लगभग एक सप्ताह।

स्वाभाविक रूप से, सभी टर्मिनल कमांड पहली बार पारित नहीं हुए, काफी बार यह निर्देश पुराना हो गया।

यह सामान्य माना जाता था और सभी को अनुकूल बनाता था। यही है, 1 घंटे के काम में एक सुविधा बनाने के लिए, सभी घटकों को स्थानीय रूप से तैनात करने के लिए 40 घंटे खर्च करना आवश्यक था।

अब विकास के लिए सभी सेवाओं के साथ परियोजना की तैनाती इस तरह दिखती है और ठंड शुरू होने के साथ लगभग 10 मिनट लगते हैं ।

 $ docker-compose up api ... Listening localhost:8080

सभी सेवा परिनियोजन आदेशों को डॉकर छवियों की असेंबली के दौरान निष्पादित किया जाता है। वे स्वचालित हैं और पुराने नहीं हो सकते।

केस 2. स्थिरता

दूसरा मामला हमारे काम करने वाले कंप्यूटर की प्रणाली की स्थिरता है।

कौन अपने पसंदीदा कंप्यूटर पर कुछ तृतीय - पक्ष सॉफ़्टवेयर रखना पसंद करता है? कई अलग-अलग डेटाबेस , नए कंपाइलर , दुभाषियों को कौन स्थापित करना पसंद करता है?

और यह तब करना पड़ता है जब हम स्थानीय रूप से तीसरे पक्ष के एपीआई को तैनात करते हैं।

इसके अलावा, आप अपने सिस्टम को तोड़ सकते हैं और इसे बहाल करने में कई घंटे बिता सकते हैं।

विकास के लिए डॉकर का उपयोग करना इस समस्या का बहुत अच्छा काम करता है। सभी तृतीय-पक्ष सॉफ़्टवेयर अछूता कंटेनरों में घूमते हैं और यदि आवश्यक हो तो आसानी से निकाल दिए जाते हैं ।

 $ docker rm --volumes api $ docker system prune --all

केस 3. हम ऑपरेशन को नियंत्रित करते हैं

और तीसरा मामला जिसके बारे में मैं बात करना चाहूंगा, वह है फ्रंट-एंड डेवलपर की क्षमता उसकी सेवा के संचालन को नियंत्रित करना। यह आपको तय करना है कि उसकी सेवा उत्पादन में कैसे काम करेगी।

मुझे पता है कि एक परियोजना के संचालन में काफी बार ऐसा दिखता है।

सामने: दोस्तों, मैंने सब कुछ किया। शलजम में कोड। रोल आउट, प्लिज़!
व्यवस्थापक: यह कैसे रोल आउट करता है?
मोर्चा: आप नोड एकत्र करते हैं और वेब सर्वर द्वारा /build फ़ोल्डर से स्टैटिक्स वितरित करते हैं
व्यवस्थापक: नोड के किस संस्करण को इकट्ठा करना है? बिल्ड कमांड क्या है? किस वेब सर्वर को वितरित करना है?

नतीजतन, व्यवस्थापक के लिए, आपकी परियोजना की तैनाती एक कम रोमांचक खोज में बदल जाती है, जैसा कि आपके लिए पिछले मामलों से स्थानीय मशीन पर एपीआई की तैनाती है।

यहां तक कि अगर परियोजना आपके कंप्यूटर पर काम करेगी, तो यह बिल्कुल भी आवश्यक नहीं है कि सब कुछ उत्पादन पर भी काम करेगा। और हमें क्लासिक समस्या मिलती है " यह मेरी मशीन पर काम करता है ।"

डॉकर इसमें हमारी मदद करता है। समाधान सरल है, अगर हमने डॉकटर में अपनी परियोजना को पैक किया, जिससे इसकी असेंबली को स्वचालित किया गया और लॉन्च की स्थापना की गई, तो यह सभी सर्वरों पर समान रूप से काम करेगा जो डॉकर का समर्थन करते हैं।

प्रवेश के लिए एक गाइड नीचे आता है:

सामने: दोस्तों, मैंने सब कुछ किया। आपके लिए एक डॉकर छवि एकत्र की। रोल आउट, प्लिज़!
व्यवस्थापक: ठीक है

खैर, क्या, और प्रशंसा के साथ निश्चित रूप से डॉकर छवियों के साथ काम करने में सक्षम होना चाहिए। हमारे नोड के साथ ऐसा नहीं है।

कर्ता क्या है?

मुझे आशा है कि मैं समझा सकता हूं कि अगर आप फ्रंट-एंड डेवलपर हैं और फिर भी यह नहीं जानते हैं तो आपको इस तकनीक पर बारीकी से ध्यान देना चाहिए। लेकिन मैंने कभी नहीं बताया कि यह क्या है।

मैं लेख के निम्नलिखित भागों में इसके बारे में लिखने और फ्रंट-एंड डेवलपर्स के लिए कुछ उपयोगी व्यंजनों को देने की योजना बना रहा हूं।

अपडेट किया गया

पॉडकास्ट वेब मानकों में चर्चा लेख

सामने के छोर के लिए डॉकटर। भाग 1. क्यों?