ડોકર સ્વોર્મ સાથે એપ્લિકેશનો જમાવો

અમે જે ઓનલાઈન વિડિયો કન્ટેન્ટ ભલામણ સિસ્ટમ પર કામ કરી રહ્યા છીએ તે એક બંધ વ્યાપારી વિકાસ છે અને તકનીકી રીતે માલિકી અને ઓપન સોર્સ ઘટકોનું બહુ-ઘટક ક્લસ્ટર છે. આ લેખ લખવાનો હેતુ સ્ટેજીંગ સાઈટ માટે ડોકર સ્વોર્મ ક્લસ્ટરીંગ સિસ્ટમના અમલીકરણનું વર્ણન કરવાનો છે અમારી પ્રક્રિયાઓના સ્થાપિત વર્કફ્લોને મર્યાદિત સમયમાં વિક્ષેપિત કર્યા વિના. તમારા ધ્યાન પર પ્રસ્તુત વર્ણન બે ભાગમાં વહેંચાયેલું છે. પ્રથમ ભાગ ડોકર સ્વોર્મનો ઉપયોગ કરતા પહેલા CI/CD નું વર્ણન કરે છે, અને બીજો તેના અમલીકરણની પ્રક્રિયાનું વર્ણન કરે છે. જેમને પ્રથમ ભાગ વાંચવામાં રસ નથી તેઓ સુરક્ષિત રીતે બીજા ભાગ પર જઈ શકે છે.

ભાગ I

પાછા દૂરના, દૂરના વર્ષમાં, શક્ય તેટલી ઝડપથી CI/CD પ્રક્રિયાને સેટ કરવી જરૂરી હતી. ડોકરનો ઉપયોગ ન કરવાની એક શરત હતી જમાવટ માટે ઘણા કારણોસર વિકસિત ઘટકો:

• ઉત્પાદનમાં ઘટકોની વધુ વિશ્વસનીય અને સ્થિર કામગીરી માટે (એટલે ​​​​કે, હકીકતમાં, વર્ચ્યુઅલાઈઝેશનનો ઉપયોગ ન કરવાની જરૂરિયાત)
• અગ્રણી વિકાસકર્તાઓ ડોકર સાથે કામ કરવા માંગતા ન હતા (વિચિત્ર, પરંતુ તે કેવી રીતે હતું)
• આર એન્ડ ડી મેનેજમેન્ટની વૈચારિક વિચારણાઓ અનુસાર

MVP માટે ઇન્ફ્રાસ્ટ્રક્ચર, સ્ટેક અને અંદાજિત પ્રારંભિક જરૂરિયાતો નીચે પ્રમાણે રજૂ કરવામાં આવી હતી:

• ડેબિયન સાથે 4 Intel® X5650 સર્વર્સ (એક વધુ શક્તિશાળી મશીન સંપૂર્ણપણે વિકસિત છે)
• C++, Python3 માં પોતાના કસ્ટમ ઘટકોનો વિકાસ હાથ ધરવામાં આવે છે
• વપરાયેલ મુખ્ય 3જી પક્ષ સાધનો: કાફકા, ક્લિકહાઉસ, એરફ્લો, રેડિસ, ગ્રાફના, પોસ્ટગ્રેસ્કલ, માયએસક્યુએલ, …
• ડીબગ અને રીલીઝ માટે અલગથી ઘટકોના નિર્માણ અને પરીક્ષણ માટે પાઇપલાઇન્સ

પ્રથમ પ્રશ્નોમાંથી એક કે જેને પ્રારંભિક તબક્કે સંબોધિત કરવાની જરૂર છે તે એ છે કે કસ્ટમ ઘટકો કોઈપણ પર્યાવરણ (CI/CD) માં કેવી રીતે જમાવવામાં આવશે.

અમે તૃતીય-પક્ષ ઘટકોને પ્રણાલીગત રીતે ઇન્સ્ટોલ કરવાનું અને તેમને વ્યવસ્થિત રીતે અપડેટ કરવાનું નક્કી કર્યું. C++ અથવા Python માં વિકસિત કસ્ટમ એપ્લિકેશનો ઘણી રીતે ગોઠવી શકાય છે. તેમાંથી, ઉદાહરણ તરીકે: સિસ્ટમ પેકેજો બનાવવા, તેમને બિલ્ટ ઈમેજોના રીપોઝીટરીમાં મોકલવા અને પછી સર્વર્સ પર ઇન્સ્ટોલ કરવા. અજ્ઞાત કારણોસર, બીજી પદ્ધતિ પસંદ કરવામાં આવી હતી, એટલે કે: CI નો ઉપયોગ કરીને, એપ્લિકેશન એક્ઝિક્યુટેબલ ફાઇલો કમ્પાઇલ કરવામાં આવે છે, વર્ચ્યુઅલ પ્રોજેક્ટ પર્યાવરણ બનાવવામાં આવે છે, py મોડ્યુલો જરૂરીયાત.txt થી ઇન્સ્ટોલ કરવામાં આવે છે, અને આ તમામ આર્ટિફેક્ટ્સ રૂપરેખાઓ, સ્ક્રિપ્ટો અને સાથે મોકલવામાં આવે છે. સર્વરો માટે એપ્લિકેશન પર્યાવરણ સાથે. આગળ, એડમિનિસ્ટ્રેટર અધિકારો વિના વર્ચ્યુઅલ વપરાશકર્તા તરીકે એપ્લિકેશનો શરૂ કરવામાં આવે છે.

Gitlab-CI CI/CD સિસ્ટમ તરીકે પસંદ કરવામાં આવી હતી. પરિણામી પાઇપલાઇન કંઈક આના જેવી દેખાતી હતી:

માળખાકીય રીતે, gitlab-ci.yml આના જેવો દેખાતો હતો

---
variables:
  # минимальная версия ЦПУ на серверах, где разворачивается кластер
  CMAKE_CPUTYPE: "westmere"

  DEBIAN: "MYREGISTRY:5000/debian:latest"

before_script:
  - eval $(ssh-agent -s)
  - ssh-add <(echo "$SSH_PRIVATE_KEY")
  - mkdir -p ~/.ssh && echo -e "Host *ntStrictHostKeyChecking nonn" > ~/.ssh/config

stages:
  - build
  - testing
  - deploy

debug.debian:
  stage: build
  image: $DEBIAN
  script:
    - cd builds/release && ./build.sh
    paths:
      - bin/
      - builds/release/bin/
    when: always
release.debian:
  stage: build
  image: $DEBIAN
  script:
    - cd builds/release && ./build.sh
    paths:
      - bin/
      - builds/release/bin/
    when: always

## testing stage
tests.codestyle:
  stage: testing
  image: $DEBIAN
  dependencies:
    - release.debian
  script:
    - /bin/bash run_tests.sh -t codestyle -b "${CI_COMMIT_REF_NAME}_codestyle"
tests.debug.debian:
  stage: testing
  image: $DEBIAN
  dependencies:
    - debug.debian
  script:
    - /bin/bash run_tests.sh -e codestyle/test_pylint.py -b "${CI_COMMIT_REF_NAME}_debian_debug"
  artifacts:
    paths:
      - run_tests/username/
    when: always
    expire_in: 1 week
tests.release.debian:
  stage: testing
  image: $DEBIAN
  dependencies:
    - release.debian
  script:
    - /bin/bash run_tests.sh -e codestyle/test_pylint.py -b "${CI_COMMIT_REF_NAME}_debian_release"
  artifacts:
    paths:
      - run_tests/username/
    when: always
    expire_in: 1 week

## staging stage
deploy_staging:
  stage: deploy
  environment: staging
  image: $DEBIAN
  dependencies:
    - release.debian
  script:
    - cd scripts/deploy/ &&
        python3 createconfig.py -s $CI_ENVIRONMENT_NAME &&
        /bin/bash install_venv.sh -d -r ../../requirements.txt &&
        python3 prepare_init.d.py &&
        python3 deploy.py -s $CI_ENVIRONMENT_NAME
  when: manual

તે નોંધવું યોગ્ય છે કે એસેમ્બલી અને પરીક્ષણ તેની પોતાની ઇમેજ પર હાથ ધરવામાં આવે છે, જ્યાં તમામ જરૂરી સિસ્ટમ પેકેજો પહેલેથી જ ઇન્સ્ટોલ થઈ ગયા છે અને અન્ય સેટિંગ્સ કરવામાં આવી છે.

જો કે નોકરીઓમાં આ દરેક સ્ક્રિપ્ટ તેની રીતે રસપ્રદ છે, પરંતુ અલબત્ત હું તેના વિશે વાત કરીશ નહીં. તે દરેકના વર્ણનમાં ઘણો સમય લાગશે અને આ લેખનો હેતુ નથી. હું તમારું ધ્યાન ફક્ત એ હકીકત તરફ ખેંચીશ કે જમાવટના તબક્કામાં કૉલિંગ સ્ક્રિપ્ટનો ક્રમ હોય છે:

1. createconfig.py - અનુગામી જમાવટ (પૂર્વઉત્પાદન, ઉત્પાદન, પરીક્ષણ, ...) માટે વિવિધ વાતાવરણમાં ઘટક સેટિંગ્સ સાથે settings.ini ફાઇલ બનાવે છે.
2. install_venv.sh - ચોક્કસ નિર્દેશિકામાં py ઘટકો માટે વર્ચ્યુઅલ પર્યાવરણ બનાવે છે અને તેને રિમોટ સર્વર્સ પર નકલ કરે છે
3. તૈયારી_init.d.py - નમૂનાના આધારે ઘટક માટે સ્ટાર્ટ-સ્ટોપ સ્ક્રિપ્ટો તૈયાર કરે છે
4. deploy.py - નવા ઘટકોનું વિઘટન અને પુનઃપ્રારંભ કરે છે

સમય પસાર થયો. સ્ટેજીંગ સ્ટેજને પૂર્વઉત્પાદન અને ઉત્પાદન દ્વારા બદલવામાં આવ્યું હતું. એક વધુ વિતરણ (CentOS) પર ઉત્પાદન માટે સમર્થન ઉમેર્યું. 5 વધુ શક્તિશાળી ભૌતિક સર્વર અને એક ડઝન વર્ચ્યુઅલ સર્વર ઉમેર્યા. અને વિકાસકર્તાઓ અને પરીક્ષકો માટે કાર્યકારી સ્થિતિની નજીકના વાતાવરણમાં તેમના કાર્યોનું પરીક્ષણ કરવું વધુને વધુ મુશ્કેલ બન્યું. આ સમયે, તે સ્પષ્ટ થઈ ગયું કે તેના વિના કરવું અશક્ય હતું ...

ભાગ II

તેથી, અમારું ક્લસ્ટર એ બે ડઝન અલગ ઘટકોની અદભૂત સિસ્ટમ છે જેનું વર્ણન Dockerfiles દ્વારા કરવામાં આવ્યું નથી. તમે તેને સામાન્ય રીતે ચોક્કસ વાતાવરણમાં જમાવટ માટે જ ગોઠવી શકો છો. અમારું કાર્ય ક્લસ્ટરને પ્રી-રિલીઝ ટેસ્ટિંગ પહેલાં ચકાસવા માટે સ્ટેજીંગ એન્વાયર્નમેન્ટમાં જમાવવાનું છે.

સૈદ્ધાંતિક રીતે, એકસાથે ચાલી રહેલા ઘણા ક્લસ્ટરો હોઈ શકે છે: જેટલા કાર્યો પૂર્ણ સ્થિતિમાં હોય અથવા પૂર્ણ થવાની નજીક હોય. અમારા નિકાલ પર સર્વરની ક્ષમતા અમને દરેક સર્વર પર ઘણા ક્લસ્ટર ચલાવવાની મંજૂરી આપે છે. દરેક સ્ટેજીંગ ક્લસ્ટરને અલગ કરવું આવશ્યક છે (બંદરો, ડિરેક્ટરીઓ વગેરેમાં કોઈ ઓવરલેપ હોવું જોઈએ નહીં).

અમારું સૌથી મૂલ્યવાન સંસાધન અમારો સમય છે, અને અમારી પાસે તેમાંથી વધુ નહોતું.

ઝડપી શરૂઆત માટે, અમે તેની સરળતા અને આર્કિટેક્ચર લવચીકતાને કારણે ડોકર સ્વોર્મ પસંદ કર્યું છે. અમે જે પ્રથમ વસ્તુ કરી તે રીમોટ સર્વર્સ પર મેનેજર અને ઘણા નોડ્સ બનાવ્યા:

$ docker node ls
ID                            HOSTNAME            STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION
kilqc94pi2upzvabttikrfr5d     nop-test-1     Ready               Active                                  19.03.2
jilwe56pl2zvabupryuosdj78     nop-test-2     Ready               Active                                  19.03.2
j5a4yz1kr2xke6b1ohoqlnbq5 *   nop-test-3     Ready               Active              Leader              19.03.2

આગળ, નેટવર્ક બનાવો:

$ docker network create --driver overlay --subnet 10.10.10.0/24 nw_swarm

આગળ, અમે CI ના નોડ્સના રિમોટ કંટ્રોલના સંદર્ભમાં Gitlab-CI અને Swarm નોડ્સને કનેક્ટ કર્યા: પ્રમાણપત્રો ઇન્સ્ટોલ કરવા, ગુપ્ત ચલો સેટ કરવા અને નિયંત્રણ સર્વર પર ડોકર સેવા સેટ કરવી. આ એક લેખ અમારો ઘણો સમય બચાવ્યો.

આગળ, અમે .gitlab-ci .yml માં સ્ટેક બનાવટ અને વિનાશની નોકરીઓ ઉમેરી.

.gitlab-ci .yml માં થોડી વધુ નોકરીઓ ઉમેરવામાં આવી છે

## staging stage
deploy_staging:
  stage: testing
  before_script:
    - echo "override global 'before_script'"
  image: "REGISTRY:5000/docker:latest"
  environment: staging
  dependencies: []
  variables:
    DOCKER_CERT_PATH: "/certs"
    DOCKER_HOST: tcp://10.50.173.107:2376
    DOCKER_TLS_VERIFY: 1
    CI_BIN_DEPENDENCIES_JOB: "release.centos.7"
  script:
    - mkdir -p $DOCKER_CERT_PATH
    - echo "$TLSCACERT" > $DOCKER_CERT_PATH/ca.pem
    - echo "$TLSCERT" > $DOCKER_CERT_PATH/cert.pem
    - echo "$TLSKEY" > $DOCKER_CERT_PATH/key.pem
    - docker stack deploy -c docker-compose.yml ${CI_ENVIRONMENT_NAME}_${CI_COMMIT_REF_NAME} --with-registry-auth
    - rm -rf $DOCKER_CERT_PATH
  when: manual

## stop staging stage
stop_staging:
  stage: testing
  before_script:
    - echo "override global 'before_script'"
  image: "REGISTRY:5000/docker:latest"
  environment: staging
  dependencies: []
  variables:
    DOCKER_CERT_PATH: "/certs"
    DOCKER_HOST: tcp://10.50.173.107:2376
    DOCKER_TLS_VERIFY: 1
  script:
    - mkdir -p $DOCKER_CERT_PATH
    - echo "$TLSCACERT" > $DOCKER_CERT_PATH/ca.pem
    - echo "$TLSCERT" > $DOCKER_CERT_PATH/cert.pem
    - echo "$TLSKEY" > $DOCKER_CERT_PATH/key.pem
    - docker stack rm ${CI_ENVIRONMENT_NAME}_${CI_COMMIT_REF_NAME}
    # TODO: need check that stopped
  when: manual

ઉપરોક્ત કોડ સ્નિપેટમાંથી, તમે જોઈ શકો છો કે બે બટનો (ડિપ્લોય_સ્ટેજિંગ, સ્ટોપ_સ્ટેજિંગ) પાઇપલાઇન્સમાં ઉમેરવામાં આવ્યા છે, જેને મેન્યુઅલ એક્શનની જરૂર છે.

સ્ટેકનું નામ શાખાના નામ સાથે મેળ ખાય છે અને આ વિશિષ્ટતા પૂરતી હોવી જોઈએ. સ્ટેકમાંની સેવાઓ અનન્ય આઈપી એડ્રેસ અને પોર્ટ્સ, ડિરેક્ટરીઓ વગેરે મેળવે છે. અલગ કરવામાં આવશે, પરંતુ સ્ટેકથી સ્ટેક સુધી સમાન (કારણ કે રૂપરેખાંકન ફાઇલ બધા સ્ટેક્સ માટે સમાન છે) - અમે જે ઇચ્છતા હતા. અમે સ્ટેક (ક્લસ્ટર) નો ઉપયોગ કરીને જમાવટ કરીએ છીએ ડોકર-કંપોઝ.એમએમએલ, જે અમારા ક્લસ્ટરનું વર્ણન કરે છે.

ડોકર-કંપોઝ.એમએમએલ

---
version: '3'

services:
  userprop:
    image: redis:alpine
    deploy:
      replicas: 1
      placement:
        constraints: [node.id == kilqc94pi2upzvabttikrfr5d]
      restart_policy:
        condition: none
    networks:
      nw_swarm:
  celery_bcd:
    image: redis:alpine
    deploy:
      replicas: 1
      placement:
        constraints: [node.id == kilqc94pi2upzvabttikrfr5d]
      restart_policy:
        condition: none
    networks:
      nw_swarm:

  schedulerdb:
    image: mariadb:latest
    environment:
      MYSQL_ALLOW_EMPTY_PASSWORD: 'yes'
      MYSQL_DATABASE: schedulerdb
      MYSQL_USER: ****
      MYSQL_PASSWORD: ****
    command: ['--character-set-server=utf8mb4', '--collation-server=utf8mb4_unicode_ci', '--explicit_defaults_for_timestamp=1']
    deploy:
      replicas: 1
      placement:
        constraints: [node.id == kilqc94pi2upzvabttikrfr5d]
      restart_policy:
        condition: none
    networks:
      nw_swarm:

  celerydb:
    image: mariadb:latest
    environment:
      MYSQL_ALLOW_EMPTY_PASSWORD: 'yes'
      MYSQL_DATABASE: celerydb
      MYSQL_USER: ****
      MYSQL_PASSWORD: ****
    deploy:
      replicas: 1
      placement:
        constraints: [node.id == kilqc94pi2upzvabttikrfr5d]
      restart_policy:
        condition: none
    networks:
      nw_swarm:

  cluster:
    image: $CENTOS7
    environment:
      - CENTOS
      - CI_ENVIRONMENT_NAME
      - CI_API_V4_URL
      - CI_REPOSITORY_URL
      - CI_PROJECT_ID
      - CI_PROJECT_URL
      - CI_PROJECT_PATH
      - CI_PROJECT_NAME
      - CI_COMMIT_REF_NAME
      - CI_BIN_DEPENDENCIES_JOB
    command: >
      sudo -u myusername -H /bin/bash -c ". /etc/profile &&
        mkdir -p /storage1/$CI_COMMIT_REF_NAME/$CI_PROJECT_NAME &&
        cd /storage1/$CI_COMMIT_REF_NAME/$CI_PROJECT_NAME &&
            git clone -b $CI_COMMIT_REF_NAME $CI_REPOSITORY_URL . &&
            curl $CI_API_V4_URL/projects/$CI_PROJECT_ID/jobs/artifacts/$CI_COMMIT_REF_NAME/download?job=$CI_BIN_DEPENDENCIES_JOB -o artifacts.zip &&
            unzip artifacts.zip ;
        cd /storage1/$CI_COMMIT_REF_NAME/$CI_PROJECT_NAME/scripts/deploy/ &&
            python3 createconfig.py -s $CI_ENVIRONMENT_NAME &&
            /bin/bash install_venv.sh -d -r ../../requirements.txt &&
            python3 prepare_init.d.py &&
            python3 deploy.py -s $CI_ENVIRONMENT_NAME"
    deploy:
      replicas: 1
      placement:
        constraints: [node.id == kilqc94pi2upzvabttikrfr5d]
      restart_policy:
        condition: none
    tty: true
    stdin_open: true
    networks:
      nw_swarm:

networks:
  nw_swarm:
    external: true

અહીં તમે જોઈ શકો છો કે ઘટકો એક નેટવર્ક (nw_swarm) દ્વારા જોડાયેલા છે અને એકબીજા માટે ઉપલબ્ધ છે.

સિસ્ટમ ઘટકો (redis, mysql પર આધારિત) કસ્ટમ ઘટકોના સામાન્ય પૂલથી અલગ કરવામાં આવે છે (યોજનાઓમાં અને કસ્ટમને સેવાઓ તરીકે વિભાજિત કરવામાં આવે છે). અમારા ક્લસ્ટરનો જમાવટનો તબક્કો અમારી એક મોટી રૂપરેખાંકિત ઈમેજમાં CMD પસાર કરવા જેવો દેખાય છે અને સામાન્ય રીતે, ભાગ I માં વર્ણવેલ જમાવટથી વ્યવહારીક રીતે અલગ નથી. હું તફાવતોને પ્રકાશિત કરીશ:

• git ક્લોન... - જમાવટ કરવા માટે જરૂરી ફાઇલો મેળવો (createconfig.py, install_venv.sh, વગેરે)
• કર્લ... && અનઝિપ કરો... - બિલ્ડ આર્ટિફેક્ટ્સ ડાઉનલોડ કરો અને અનઝિપ કરો (સંકલિત ઉપયોગિતાઓ)

ત્યાં માત્ર એક જ હજુ સુધી વર્ણવી ન શકાય તેવી સમસ્યા છે: વેબ ઈન્ટરફેસ ધરાવતા ઘટકો વિકાસકર્તાઓના બ્રાઉઝર્સથી ઍક્સેસિબલ નથી. અમે રિવર્સ પ્રોક્સીનો ઉપયોગ કરીને આ સમસ્યાને હલ કરીએ છીએ, આમ:

.gitlab-ci.yml માં, ક્લસ્ટર સ્ટેકને જમાવવા પછી, અમે બેલેન્સરને જમાવવાની લાઇન ઉમેરીએ છીએ (જે, જ્યારે કમિટ કરે છે, ત્યારે માત્ર તેનું રૂપરેખાંકન અપડેટ કરે છે (નમૂના અનુસાર નવી nginx રૂપરેખાંકન ફાઇલો બનાવે છે: /etc/nginx/conf. d/${CI_COMMIT_REF_NAME}.conf) - docker-compose-nginx.yml કોડ જુઓ)

    - docker stack deploy -c docker-compose-nginx.yml ${CI_ENVIRONMENT_NAME} --with-registry-auth

docker-compose-nginx.yml

---
version: '3'

services:
  nginx:
    image: nginx:latest
    environment:
      CI_COMMIT_REF_NAME: ${CI_COMMIT_REF_NAME}
      NGINX_CONFIG: |-
            server {
                listen 8080;
                server_name staging_${CI_COMMIT_REF_NAME}_cluster.dev;

                location / {
                    proxy_pass http://staging_${CI_COMMIT_REF_NAME}_cluster:8080;
                }
            }
            server {
                listen 5555;
                server_name staging_${CI_COMMIT_REF_NAME}_cluster.dev;

                location / {
                    proxy_pass http://staging_${CI_COMMIT_REF_NAME}_cluster:5555;
                }
            }
    volumes:
      - /tmp/staging/nginx:/etc/nginx/conf.d
    command:
      /bin/bash -c "echo -e "$$NGINX_CONFIG" > /etc/nginx/conf.d/${CI_COMMIT_REF_NAME}.conf;
        nginx -g "daemon off;";
        /etc/init.d/nginx reload"
    ports:
      - 8080:8080
      - 5555:5555
      - 3000:3000
      - 443:443
      - 80:80
    deploy:
      replicas: 1
      placement:
        constraints: [node.id == kilqc94pi2upzvabttikrfr5d]
      restart_policy:
        condition: none
    networks:
      nw_swarm:

networks:
  nw_swarm:
    external: true

ડેવલપમેન્ટ કમ્પ્યુટર્સ પર, અપડેટ /etc/hosts; nginx ને url લખો:

10.50.173.106 staging_BRANCH-1831_cluster.dev

તેથી, આઇસોલેટેડ સ્ટેજીંગ ક્લસ્ટરોની જમાવટ લાગુ કરવામાં આવી છે અને વિકાસકર્તાઓ હવે તેમના કાર્યોને તપાસવા માટે પૂરતી સંખ્યામાં તેમને ચલાવી શકે છે.

ભવિષ્ય ની યોજનાઓ:

• અમારા ઘટકોને સેવા તરીકે અલગ કરો
• દરેક ડોકરફાઈલ માટે હોય
• સ્ટેકમાં ઓછા લોડ કરેલા નોડ્સને આપમેળે શોધો
• નામ પેટર્ન દ્વારા નોડ્સનો ઉલ્લેખ કરો (લેખમાંની જેમ આઈડીનો ઉપયોગ કરવાને બદલે)
• એક ચેક ઉમેરો કે સ્ટેક નાશ પામે છે
• ...

માટે ખાસ આભાર એક લેખ.

સોર્સ: www.habr.com