Se vi estas kiel plej multaj homoj, vi verŝajne uzas rimedojn, kiuj funkcias ekster via areto. Eble vi uzas la Taleo API por sendi tekstmesaĝojn, aŭ analizi bildojn per la Google Cloud Vision API.
Se vi uzas la saman servilflankan petan finpunkton en ĉiuj viaj medioj kaj ne planas migri viajn servilojn al Kubernetes, tiam estas tute bone havi servan finpunkton ĝuste en via kodo. Tamen, ekzistas multaj aliaj scenaroj por la disvolviĝo de eventoj. En ĉi tiu serio de Kubernetes Best Practices, vi lernos kiel uzi la enkonstruitajn mekanismojn de Kubernetes por malkovri servojn kaj ene kaj ekster la areto.
Ekzemplo de komuna ekstera servo estas datumbazo funkcianta ekstere de Kubernetes-areto. Male al nubaj datumbazoj kiel Google Cloud Data Store aŭ Google Cloud Spanner, kiuj uzas ununuran finpunkton por ĉiu aliro, plej multaj datumbazoj havas apartajn finpunktojn por malsamaj cirkonstancoj.
Plej bonaj praktikoj por uzi tradiciajn datumbazojn kiel MySQL kaj MongoDB kutime signifas, ke vi konektas al malsamaj komponantoj por malsamaj medioj. Vi povas havi grandan maŝinon por produktado-datumoj kaj pli malgrandan maŝinon por la testa medio. Ĉiu el ili havos sian propran IP-adreson aŭ domajnan nomon, sed vi verŝajne ne volos ŝanĝi vian kodon kiam vi moviĝos de unu medio al alia. Do anstataŭ malmola kodigi ĉi tiujn adresojn, vi povas uzi la enkonstruitan DNS-bazitan eksteran servon de Kubernetes same kiel denaskaj Kubernetes-servoj.
Ni diru, ke vi funkcias MongoDB-datumbazon sur Google Compute Engine. Vi estos blokita en ĉi tiu hibrida mondo ĝis vi sukcesos transdoni ĝin al la areto.
Feliĉe, vi povas uzi statikajn servojn de Kubernetes por iom plifaciligi vian vivon. En ĉi tiu ekzemplo, mi kreis MongoDB-servilon per Google Cloud Launcher. Ĉar ĝi estas kreita sur la sama reto (aŭ Kubernetes-grupo VPC), ĝi estas alirita per alt-efikeca interna IP-adreso.
Ĉi tio estas la defaŭlta agordo en Google Cloud, do vi ne devas agordi ion ajn. Nun kiam vi havas IP-adreson, la unua paŝo estas krei servon. Vi eble rimarkos, ke ne ekzistas pod-elektiloj por ĉi tiu servo. Tio estas, ni kreis servon, kiu ne scios kien sendi trafikon. Ĉi tio permesos al vi permane krei finpunktan objekton, kiu ricevos trafikon de ĉi tiu servo.
La sekva kodekzemplo montras, ke la finpunktoj determinas la IP-adreson por la datumbazo uzante la saman mongo-nomon kiel la servo.
Kubernetes uzos ĉiujn IP-adresojn por trovi finpunktojn kvazaŭ ili estus regulaj Kubernetes Pods, do nun vi povas aliri la datumbazon per simpla koneksa ĉeno al la supra nomo mongodb://mongo. Tute ne necesas uzi IP-adresojn en via kodo.
Se IP-adresoj ŝanĝiĝos estonte, vi povas simple ĝisdatigi viajn finpunktojn kun la nova IP-adreso kaj viaj aplikoj ne bezonos esti modifitaj aldone.
Se vi uzas datumbazon gastigitan en triaparta gastiganto, verŝajne la posedantoj de la gastiganto provizis al vi Uniform Resource Identifier URI por konektiĝi. Do se vi ricevis IP-adreson, vi povas simple uzi la antaŭan metodon. Ĉi tiu ekzemplo montras, ke mi havas du MongoDB-datumbazon gastigitajn sur mLab-gastiganto.
Unu estas la datumbazo de programistoj kaj la alia estas la datumbazo de produktado. La konektaj ĉenoj por ĉi tiuj datumbazoj aspektas tiel - mLab provizas al vi dinamikan URI kaj dinamikan havenon. Kiel vi povas vidi, ili estas malsamaj.
Por abstrakti ĉi tion, ni uzu Kubernetes kaj konektu al la programista datumbazo. Vi povas krei eksteran servonomon de Kubernetes, kiu donos al vi statikan servon, kiu plusendos trafikon al la ekstera servo.
Ĉi tiu servo plenumos simplan CNAME-sendadon ĉe la kernnivelo kun minimuma efikeco. Dank' al tio vi povas uzi pli simplan konektan ĉenon.
Sed ĉar la ekstera nomo uzas CNAME-sendon, ĝi ne povas plenumi haven-sendadon. Tial ĉi tiu solvo nur aplikeblas por senmovaj havenoj kaj ne povas esti uzata kun dinamikaj havenoj. Sed mLab Free Tier donas al la uzanto dinamikan havenon defaŭlte kaj vi ne povas ŝanĝi ĝin. Ĉi tio signifas, ke vi bezonas malsamajn konektajn komandliniojn por dev kaj prod. La malbona afero estas, ke ĉi tio postulos vin malmola kodigo de la havena numero. Do kiel vi funkciigas havenon?
La unua paŝo estas akiri la IP-adreson de la URI. Se vi rulas nslookup, gastigan nomon aŭ ping la URI, vi povas ricevi la IP-adreson de la datumbazo. Se la servo resendas plurajn IP-adresojn al vi, tiam ĉiuj ĉi tiuj adresoj povas esti uzataj ĉe la finpunktoj de la objekto.
Unu afero memorinda estas, ke IP-URIoj povas ŝanĝiĝi sen avizo, igante ilin sufiĉe riskaj uzi en prod. Uzante ĉi tiun IP-adreson, vi povas konektiĝi al fora datumbazo sen specifi havenon. Tiel, la servo Kubernetes plenumas haven-sendadon sufiĉe travideble.
Mapado, aŭ mapado de eksteraj rimedoj al internaj, donas al vi la flekseblecon por uzi ĉi tiujn servojn ene de la areto estonte dum minimumigo de refaktoraj klopodoj. Ĝi ankaŭ faciligas administri kaj doni informojn pri kiaj eksteraj servoj uzas via kompanio.
Daŭrigota tre baldaŭ...
Kelkaj reklamoj 🙂
Dankon pro restado ĉe ni. Ĉu vi ŝatas niajn artikolojn? Ĉu vi volas vidi pli interesan enhavon? Subtenu nin farante mendon aŭ rekomendante al amikoj, , unika analogo de enirnivelaj serviloj, kiu estis inventita de ni por vi: (havebla kun RAID1 kaj RAID10, ĝis 24 kernoj kaj ĝis 40GB DDR4).
Dell R730xd 2 fojojn pli malmultekosta en Equinix Tier IV datumcentro en Amsterdamo? Nur ĉi tie en Nederlando! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ekde $99! Legu pri
fonto: www.habr.com