Docker Swarm-ը, Kubernetes-ը և Mesos-ը կոնտեյներային նվագախմբերի ամենահայտնի շրջանակներն են: Իր ելույթում Արուն Գուպտան համեմատում է Docker-ի, Swarm-ի և Kubernetes-ի հետևյալ ասպեկտները.
- Տեղական զարգացում.
- Տեղակայման գործառույթներ.
- Multi-container հավելվածներ.
- Ծառայության բացահայտում.
- Ծառայության մասշտաբը.
- Միանգամյա առաջադրանքներ:
- Ինտեգրում Maven-ի հետ:
- «Գլորվող» թարմացում.
- Couchbase տվյալների բազայի կլաստերի ստեղծում:
Արդյունքում, դուք հստակ կհասկանաք, թե ինչ կարող է առաջարկել նվագախմբի յուրաքանչյուր գործիք և կսովորեք, թե ինչպես արդյունավետ օգտագործել այս հարթակները:
Արուն Գուպտան Amazon Web Services-ի բաց կոդով արտադրանքների գլխավոր տեխնոլոգն է, ով ավելի քան 10 տարի զարգացնում է Sun, Oracle, Red Hat և Couchbase ծրագրավորողների համայնքները: Ունի աշխատելու մեծ փորձ առաջատար միջֆունկցիոնալ թիմերում, որոնք մշակում և իրականացնում են մարքեթինգային արշավների և ծրագրերի ռազմավարություն: Նա ղեկավարել է Sun-ի ինժեներների թիմերը, Java EE թիմի հիմնադիրներից է և Devoxx4Kids-ի ԱՄՆ մասնաճյուղի ստեղծողը: Արուն Գուպտան ավելի քան 2 հազար հրապարակումների հեղինակ է ՏՏ բլոգներում և ելույթներ է ունեցել ավելի քան 40 երկրներում։
Տող 55-ը պարունակում է COUCHBASE_URI, որը ցույց է տալիս տվյալների բազայի այս ծառայությունը, որը նույնպես ստեղծվել է Kubernetes-ի կազմաձևման ֆայլի միջոցով: Եթե նայեք տող 2-ին, կարող եք տեսնել տեսակը. Ծառայությունը իմ ստեղծած ծառայությունն է, որը կոչվում է couchbase-service, և նույն անունը նշված է տող 4-ում: Ստորև բերված են մի քանի նավահանգիստներ:
Հիմնական տողերն են 6-ը և 7-ը: Ծառայության ընթացքում ես ասում եմ. «Հեյ, սրանք այն պիտակներն են, որոնք ես փնտրում եմ», և այս պիտակները ոչ այլ ինչ են, քան փոփոխական զույգերի անունները, և 7-րդ տողը ցույց է տալիս իմ couchbase-rs-pod-ը: դիմումը. Ստորև բերված են այն նավահանգիստները, որոնք ապահովում են մուտք դեպի այս նույն պիտակները:
19-րդ տողում ես ստեղծում եմ նոր տեսակի ReplicaSet, տող 31-ը պարունակում է պատկերի անունը, իսկ 24-27 տողերը մատնանշում են իմ պատի հետ կապված մետատվյալները: Սա հենց այն է, ինչ փնտրում է ծառայությունը և ինչի հետ պետք է կապ հաստատել: Ֆայլի վերջում կա մի տեսակ կապ 55-56 և 4 տողերի միջև՝ ասելով.
Այսպիսով, ես սկսում եմ իմ ծառայությունը, երբ կա կրկնօրինակների հավաքածու, և քանի որ յուրաքանչյուր կրկնօրինակ հավաքածու ունի իր պորտը՝ համապատասխան պիտակով, այն ներառված է ծառայության մեջ։ Մշակողի տեսանկյունից դուք պարզապես զանգահարում եք ծառայություն, որն այնուհետ օգտագործում է ձեզ անհրաժեշտ կրկնօրինակների հավաքածուն:
Արդյունքում, ես ունեմ WildFly pod, որը հաղորդակցվում է տվյալների բազայի հետ Couchbase ծառայության միջոցով: Ես կարող եմ օգտագործել frontend-ը մի քանի WildFly pods-ի հետ, որը նաև շփվում է couchbase backend-ի հետ couchbase ծառայության միջոցով:
Հետագայում մենք կանդրադառնանք, թե ինչպես է կլաստերի սահմաններից դուրս գտնվող ծառայությունը հաղորդակցվում իր IP հասցեի միջոցով տարրերի հետ, որոնք գտնվում են կլաստերի ներսում և ունեն ներքին IP հասցե:
Այսպիսով, քաղաքացիություն չունեցող բեռնարկղերը հիանալի են, բայց որքանո՞վ է լավ պետական բեռնարկղերի օգտագործումը: Եկեք նայենք պետական կամ մշտական բեռնարկղերի համակարգի կարգավորումներին: Docker-ում տվյալների պահպանման դասավորության 4 տարբեր մոտեցում կա, որոնց պետք է ուշադրություն դարձնել: Առաջինը Implicit Per-Container-ն է, ինչը նշանակում է, որ couchbase, MySQL կամ MyDB հագեցած կոնտեյներներ օգտագործելիս նրանք բոլորը սկսում են լռելյայն Sandbox-ից: Այսինքն՝ այն ամենը, ինչ պահվում է տվյալների բազայում, պահվում է հենց կոնտեյների մեջ։ Եթե կոնտեյները անհետանում է, ապա դրա հետ միասին անհետանում են նաև տվյալները:
Երկրորդը Explicit Per-Container-ն է, երբ դուք ստեղծում եք հատուկ պահեստ՝ docker volume-ով, ստեղծել հրամանը և պահել տվյալները դրանում: Երրորդ Per-Host մոտեցումը կապված է պահեստավորման քարտեզագրման հետ, երբ կոնտեյներով պահվող ամեն ինչ միաժամանակ կրկնօրինակվում է հյուրընկալողի վրա: Եթե բեռնարկղը ձախողվի, տվյալները կմնան հոսթի վրա: Վերջինս մի քանի Multi-Host հոսթների օգտագործումն է, որը նպատակահարմար է տարբեր լուծումների արտադրության փուլում։ Ենթադրենք, որ ձեր հավելվածներով ձեր կոնտեյներները աշխատում են հոսթում, բայց դուք ցանկանում եք ձեր տվյալները պահել ինտերնետում ինչ-որ տեղ, և դրա համար դուք օգտագործում եք ավտոմատ քարտեզագրում բաշխված համակարգերի համար:
Այս մեթոդներից յուրաքանչյուրն օգտագործում է հատուկ պահեստավորման վայր: Implicit and Explicit Per-Container-ի տվյալները պահում են հոսթի վրա /var/lib/docker/volumes-ում: Per-Host մեթոդն օգտագործելիս պահեստը տեղադրվում է կոնտեյների ներսում, իսկ բեռնարկղը ինքնին տեղադրված է հյուրընկալողի վրա: Multihost-ների համար կարող են օգտագործվել այնպիսի լուծումներ, ինչպիսիք են Ceph, ClusterFS, NFS և այլն:
Եթե մշտական բեռնարկղը ձախողվի, պահեստավորման գրացուցակը դառնում է անհասանելի առաջին երկու դեպքերում, բայց վերջին երկու դեպքերում մուտքը պահպանվում է: Այնուամենայնիվ, առաջին դեպքում դուք կարող եք մուտք գործել շտեմարան վիրտուալ մեքենայի վրա աշխատող Docker հոսթի միջոցով: Երկրորդ դեպքում տվյալները նույնպես չեն կորչի, քանի որ դուք ստեղծել եք Explicit պահեստ։
Եթե հոսթինգը ձախողվի, պահեստավորման գրացուցակը անհասանելի է առաջին երեք դեպքերում, իսկ վերջին դեպքում կապը պահեստի հետ չի ընդհատվում: Վերջապես, առաջին դեպքում ընդհանուր գործառույթը լիովին բացառված է պահեստավորման համար, իսկ մնացածում հնարավոր է: Երկրորդ դեպքում, դուք կարող եք կիսել պահեստը, կախված նրանից, թե արդյոք ձեր տվյալների բազան աջակցում է բաշխված պահեստին, թե ոչ: Per-Host-ի դեպքում տվյալների բաշխումը հնարավոր է միայն տվյալ հոսթի վրա, իսկ multihost-ի համար այն տրամադրվում է կլաստերի ընդլայնմամբ։
Սա պետք է հաշվի առնել պետական կոնտեյներներ ստեղծելիս: Մեկ այլ օգտակար Docker գործիք է Volume plugin-ը, որն աշխատում է «մարտկոցները առկա են, բայց պետք է փոխարինվեն» սկզբունքով: Երբ դուք գործարկում եք Docker կոնտեյներ, այն ասում է. «Հեյ, տվյալների բազայով կոնտեյներ սկսելուց հետո կարող եք պահել ձեր տվյալները այս կոնտեյներով»: Սա լռելյայն հատկությունն է, բայց դուք կարող եք փոխել այն: Այս փլագինը թույլ է տալիս օգտագործել ցանցային սկավառակ կամ նմանատիպ այլ բան կոնտեյների տվյալների բազայի փոխարեն: Այն ներառում է լռելյայն դրայվեր հոսթի վրա հիմնված պահեստավորման համար և թույլ է տալիս կոնտեյների ինտեգրումը արտաքին պահեստավորման համակարգերի հետ, ինչպիսիք են Amazon EBS-ը, Azure Storage-ը և GCE Persistent սկավառակները:
Հաջորդ սլայդը ցույց է տալիս Docker Volume հավելվածի ճարտարապետությունը:
Կապույտ գույնը ներկայացնում է Docker հաճախորդը, որը կապված է կապույտ Docker հոսթի հետ, որն ունի Տեղական պահեստավորման շարժիչ, որը ձեզ տրամադրում է կոնտեյներներ տվյալների պահպանման համար: Կանաչը ցույց է տալիս Plugin Client-ը և Plugin Daemon-ը, որոնք նույնպես կապված են հյուրընկալողի հետ: Դրանք հնարավորություն են տալիս տվյալների պահպանման ցանցային պահեստում ձեզ անհրաժեշտ Storage Backend-ի տեսակի մեջ:
Docker Volume հավելվածը կարող է օգտագործվել Portworx պահեստավորման հետ: PX-Dev մոդուլը իրականում ձեր գործարկվող կոնտեյներ է, որը միանում է ձեր Docker հոսթին և թույլ է տալիս հեշտությամբ պահել տվյալները Amazon EBS-ում:
Portworx հաճախորդը թույլ է տալիս վերահսկել տարբեր պահեստային բեռնարկղերի կարգավիճակը, որոնք միացված են ձեր հոսթին: Եթե այցելեք իմ բլոգը, կարող եք կարդալ, թե ինչպես կարելի է առավելագույնս օգտագործել Portworx-ը Docker-ի միջոցով:
Kubernetes-ում պահեստավորման հայեցակարգը նման է Docker-ին և ներկայացված է դիրեկտորիաներով, որոնք հասանելի են ձեր կոնտեյների համար պատիճով: Նրանք անկախ են ցանկացած կոնտեյների կյանքի ժամկետից: Ամենատարածված պահեստավորման տեսակներն են՝ hostPath, nfs, awsElasticBlockStore և gsePersistentDisk: Եկեք նայենք, թե ինչպես են աշխատում այս խանութները Kubernetes-ում: Սովորաբար, դրանց միացման գործընթացը բաղկացած է 3 քայլից.
Առաջինն այն է, որ ինչ-որ մեկը ցանցի կողմից, սովորաբար ադմինիստրատոր, ապահովում է ձեզ մշտական պահեստավորում: Դրա համար կա համապատասխան PersistentVolume կազմաձևման ֆայլ: Այնուհետև հավելվածի մշակողը գրում է կազմաձևման ֆայլ, որը կոչվում է PersistentVolumeClaim կամ PVC պահեստավորման հարցում, որտեղ ասվում է. անհրաժեշտ է ընդամենը 50 ԳԲ»: Վերջապես, երրորդ քայլն այն է, որ ձեր հարցումը տեղադրվի որպես պահեստ, և հավելվածը, որն ունի պատիճ, կամ կրկնօրինակի հավաքածու կամ նման բան, սկսում է օգտագործել այն: Կարևոր է հիշել, որ այս գործընթացը բաղկացած է նշված 10 քայլերից և մասշտաբային է։
Հաջորդ սլայդը ցույց է տալիս AWS ճարտարապետության Kubernetes Persistence Container-ը:
Շագանակագույն ուղղանկյունի ներսում, որը ներկայացնում է Kubernetes կլաստերը, կա մեկ հիմնական հանգույց և երկու աշխատող հանգույց, որոնք նշված են դեղինով: Աշխատող հանգույցներից մեկը պարունակում է նարնջագույն պատիճ, պահեստ, կրկնօրինակ վերահսկիչ և կանաչ Docker Couchbase կոնտեյներ: Կլաստերի ներսում, հանգույցների վերևում, մանուշակագույն ուղղանկյունը ցույց է տալիս Ծառայությունը, որը հասանելի է դրսից: Այս ճարտարապետությունը առաջարկվում է տվյալներ սարքի վրա պահելու համար: Անհրաժեշտության դեպքում ես կարող եմ պահել իմ տվյալները EBS-ում կլաստերի սահմաններից դուրս, ինչպես ցույց է տրված հաջորդ սլայդում: Սա տիպիկ մոդել է մասշտաբավորման համար, բայց կա ֆինանսական ասպեկտ, որը պետք է հաշվի առնել այն օգտագործելիս. ցանցում որևէ տեղ տվյալների պահպանումը կարող է ավելի թանկ լինել, քան հոսթում: Կոնտեյներացման լուծումներ ընտրելիս սա ծանրակշիռ փաստարկներից մեկն է։
Ինչպես Docker-ի դեպքում, դուք կարող եք օգտագործել մշտական Kubernetes կոնտեյներներ Portworx-ով:
Սա այն է, ինչ Kubernetes 1.6-ի ներկայիս տերմինաբանության մեջ կոչվում է «StatefulSet»՝ Stateful հավելվածների հետ աշխատելու միջոց, որը մշակում է Pod-ի դադարեցման և Graceful Shutdown-ի կատարման հետ կապված իրադարձությունները: Մեր դեպքում նման հավելվածները տվյալների բազաներ են։ Իմ բլոգում դուք կարող եք կարդալ, թե ինչպես ստեղծել StatefulSet Kubernetes-ում՝ օգտագործելով Portworx-ը:
Խոսենք զարգացման ասպեկտի մասին։ Ինչպես ասացի, Docker-ն ունի 2 տարբերակ՝ CE և EE, առաջին դեպքում խոսքը Community Edition-ի կայուն տարբերակի մասին է, որը թարմացվում է 3 ամիսը մեկ՝ ի տարբերություն EE-ի ամսական թարմացված տարբերակի։ Դուք կարող եք ներբեռնել Docker Mac-ի, Linux-ի կամ Windows-ի համար: Տեղադրվելուց հետո Docker-ը ավտոմատ կերպով կթարմացվի, և դա շատ հեշտ է սկսել:
Kubernetes-ի համար ես նախընտրում եմ Minikube տարբերակը. դա լավ միջոց է հարթակի հետ սկսելու համար՝ ստեղծելով կլաստեր մեկ հանգույցի վրա: Մի քանի հանգույցների կլաստերներ ստեղծելու համար տարբերակների ընտրությունն ավելի լայն է. սրանք են kops, kube-aws (CoreOS+AWS), kube-up (հնացած): Եթե ցանկանում եք օգտագործել AWS-ի վրա հիմնված Kubernetes-ը, խորհուրդ եմ տալիս միանալ AWS SIG-ին, որը հանդիպում է առցանց ամեն ուրբաթ և հրապարակում է մի շարք հետաքրքիր նյութեր AWS Kubernetes-ի հետ աշխատելու վերաբերյալ:
Եկեք նայենք, թե ինչպես է իրականացվում Rolling Update-ը այս հարթակներում: Եթե կա մի քանի հանգույցների կլաստեր, ապա այն օգտագործում է պատկերի կոնկրետ տարբերակը, օրինակ՝ WildFly:1։ Շարժվող թարմացումը նշանակում է, որ պատկերի տարբերակը հաջորդաբար փոխարինվում է նորով յուրաքանչյուր հանգույցում՝ մեկը մյուսի հետևից:
Դա անելու համար ես օգտագործում եմ docker service update հրամանը (ծառայության անվանումը), որում ես նշում եմ WildFly:2 պատկերի նոր տարբերակը և թարմացման մեթոդը update-parallelism 2: Թիվ 2 նշանակում է, որ համակարգը կթարմացնի 2 հավելվածի պատկեր: միաժամանակ, ապա 10 վայրկյան թարմացման հետաձգում 10s, որից հետո հաջորդ 2 պատկերները կթարմացվեն ևս 2 հանգույցների վրա և այլն: Այս պարզ շարժական թարմացման մեխանիզմը տրամադրվում է ձեզ որպես Docker-ի մաս:
Kubernetes-ում շարժվող թարմացումն աշխատում է այսպես. Replication controller rc-ը ստեղծում է նույն տարբերակի կրկնօրինակների մի շարք, և այս webapp-rc-ի յուրաքանչյուր պատիճ տրվում է պիտակով, որը գտնվում է etcd-ում: Երբ ինձ պատիճ է պետք, ես օգտագործում եմ Application Service-ը, որպեսզի մուտք գործեմ etcd պահոց, որն ինձ տրամադրում է pod՝ օգտագործելով նշված պիտակը:
Այս դեպքում մենք ունենք 3 պատիճ Replication կարգավորիչում, որն աշխատում է WildFly տարբերակ 1-ի հավելվածում: Հետին պլանում թարմացնելիս ստեղծվում է մեկ այլ կրկնօրինակման կարգավորիչ՝ նույն անունով և ինդեքսով վերջում - xxxxx, որտեղ x-ը պատահական թվեր են, և նույն պիտակներով։ Այժմ Application Service-ն ունի երեք պատիճ՝ հավելվածի հին տարբերակով և երեք պատիճ՝ նոր տարբերակով՝ նոր Replication կարգավորիչում: Սրանից հետո հին պատյանները ջնջվում են, նոր պատիճներով վերարտադրող կարգավորիչը վերանվանվում և գործարկվում է։
Անցնենք մոնիտորինգին։ Docker-ն ունի բազմաթիվ ներկառուցված մոնիտորինգի հրամաններ: Օրինակ, docker container stats հրամանի տող ինտերֆեյսը թույլ է տալիս ամեն վայրկյան ցուցադրել կոնտեյներների վիճակի մասին տեղեկատվություն կոնսոլում` պրոցեսորի օգտագործում, սկավառակի օգտագործում, ցանցի բեռնվածություն: Docker Remote API գործիքը տրամադրում է տվյալներ այն մասին, թե ինչպես է հաճախորդը շփվում սերվերի հետ: Այն օգտագործում է պարզ հրամաններ, բայց հիմնված է Docker REST API-ի վրա: Այս դեպքում REST, Flash, Remote բառերը նույն բանն են նշանակում։ Երբ դուք շփվում եք հյուրընկալողի հետ, դա REST API է: Docker Remote API-ն թույլ է տալիս ավելի շատ տեղեկություններ ստանալ գործարկվող բեռնարկղերի մասին: Իմ բլոգը նկարագրում է Windows Server-ով այս մոնիտորինգի օգտագործման մանրամասները:
Դոկերի համակարգի իրադարձությունների մոնիտորինգը, երբ աշխատում է բազմաբնույթ հոսթինգ կլաստերը, հնարավորություն է տալիս տվյալներ ստանալ հյուրընկալողի խափանման կամ կոնտեյների վթարի մասին կոնկրետ հոսթի, մասշտաբային ծառայությունների և այլնի մասին: Սկսած Docker 1.20-ից՝ այն ներառում է Prometheus-ը, որը վերջնակետեր է ներդնում գոյություն ունեցող հավելվածներում: Սա թույլ է տալիս ստանալ չափումներ HTTP-ի միջոցով և ցուցադրել դրանք վահանակների վրա:
Մոնիտորինգի մեկ այլ հատկանիշ է cAdvisor-ը (կոնտեյներային խորհրդատուի կրճատ): Այն վերլուծում և տրամադրում է ռեսուրսների օգտագործման և կատարողականի տվյալներ գործարկվող բեռնարկղերից՝ ապահովելով Prometheus-ի չափումները անմիջապես տուփից: Այս գործիքի առանձնահատկությունն այն է, որ այն տրամադրում է միայն վերջին 60 վայրկյանի տվյալները: Հետևաբար, դուք պետք է կարողանաք հավաքել այս տվյալները և տեղադրել դրանք տվյալների բազայում, որպեսզի կարողանաք վերահսկել երկարաժամկետ գործընթացը: Այն կարող է օգտագործվել նաև վահանակի չափումները գրաֆիկորեն ցուցադրելու համար՝ օգտագործելով Grafana կամ Kibana: Իմ բլոգում կա մանրամասն նկարագրություն, թե ինչպես կարելի է օգտագործել cAdvisor-ը՝ Kibana վահանակի միջոցով կոնտեյներները վերահսկելու համար:
Հաջորդ սլայդը ցույց է տալիս, թե ինչ տեսք ունի Պրոմեթևսի վերջնակետի ելքը և ցուցադրման համար հասանելի չափումները:
Ներքևի ձախ մասում տեսնում եք HTTP հարցումների, պատասխանների և այլնի չափումներ, իսկ աջ կողմում՝ դրանց գրաֆիկական ցուցադրումը:
Kubernetes-ը ներառում է նաև ներկառուցված մոնիտորինգի գործիքներ: Այս սլայդը ցույց է տալիս տիպիկ կլաստեր, որը պարունակում է մեկ հիմնական և երեք աշխատող հանգույց:
Աշխատանքային հանգույցներից յուրաքանչյուրը պարունակում է ավտոմատ գործարկվող cAdvisor: Բացի այդ, կա Heapster՝ կատարողականի մոնիտորինգի և չափումների հավաքման համակարգ, որը համատեղելի է Kubernetes 1.0.6 և ավելի բարձր տարբերակի հետ: Heapster-ը թույլ է տալիս հավաքել ոչ միայն աշխատանքային ծանրաբեռնվածության, պատյանների և բեռնարկղերի կատարողականի ցուցանիշներ, այլ նաև իրադարձություններ և այլ ազդանշաններ, որոնք առաջանում են ամբողջ կլաստերի կողմից: Տվյալներ հավաքելու համար այն խոսում է յուրաքանչյուր pod-ի Kubelet-ի հետ, ավտոմատ կերպով պահում է տեղեկատվությունը InfluxDB տվյալների բազայում և այն որպես չափումներ ուղարկում Grafana վահանակին: Այնուամենայնիվ, հիշեք, որ եթե դուք օգտվում եք miniKube-ից, ապա այս գործառույթը լռելյայն հասանելի չէ, այնպես որ դուք ստիպված կլինեք օգտագործել հավելումներ մոնիտորինգի համար: Այսպիսով, ամեն ինչ կախված է նրանից, թե որտեղ եք գործարկում բեռնարկղերը և մոնիտորինգի որ գործիքները կարող եք օգտագործել լռելյայն, և որոնք պետք է տեղադրեք որպես առանձին հավելումներ:
Հաջորդ սլայդը ցույց է տալիս Grafana վահանակները, որոնք ցույց են տալիս իմ բեռնարկղերի շահագործման կարգավիճակը: Այստեղ բավականին շատ հետաքրքիր տվյալներ կան։ Իհարկե, կան բազմաթիվ առևտրային Docker և Kubernetes գործընթացների մոնիտորինգի գործիքներ, ինչպիսիք են SysDig, DataDog, NewRelic: Դրանցից ոմանք ունեն 30 տարվա անվճար փորձաշրջան, այնպես որ կարող եք փորձել և գտնել այն, որը լավագույնս համապատասխանում է ձեզ: Անձամբ ես նախընտրում եմ օգտագործել SysDig-ը և NewRelic-ը, որոնք լավ են ինտեգրվում Kubernetes-ի հետ: Կան գործիքներ, որոնք հավասարապես լավ են ինտեգրվում ինչպես Docker, այնպես էլ Kubernetes հարթակներում:
Մի քանի գովազդ 🙂
Շնորհակալություն մեզ հետ մնալու համար: Ձեզ դուր են գալիս մեր հոդվածները: Ցանկանու՞մ եք տեսնել ավելի հետաքրքիր բովանդակություն: Աջակցեք մեզ՝ պատվիրելով կամ խորհուրդ տալով ընկերներին, , մուտքի մակարդակի սերվերների եզակի անալոգ, որը հորինվել է մեր կողմից ձեզ համար. (հասանելի է RAID1 և RAID10-ով, մինչև 24 միջուկով և մինչև 40 ԳԲ DDR4):
Dell R730xd 2 անգամ ավելի էժան Ամստերդամի Equinix Tier IV տվյալների կենտրոնում: Միայն այստեղ Նիդեռլանդներում! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-ից: Կարդացեք մասին
Source: www.habr.com