Если вы видите что-то необычное, просто сообщите мне. Skip to main content

Как разворачивать MongoDB в Kubernetes

Как развернуть и запустить высокодоступный сервис MongoDB в Kubernetes, используя deployments, secret, configMaps и persistent volumes.

MongoDB это проект с открытым исходным кодом, главной целью которого,документо ориентированная распределенная NOSQL база данных, которая в основном популярна на JavaScript проектах. В этой инструкции вы научитесь разворачивать и запускать MongoDB в Kubernetes.

Содержание

  • Изучим безопасное использование ключей с помощью Kubernetes secrets.
  • Изучим настроку MongoDB используя ConfigMaps.
  • Изучим использование Kubernetes Deployment для высокой доступности.
  • Изучим хранение данных с помощью Presistent Volume Claims.
  • Изучим бэкапирование базы данных используя Kubernetes CronJobs.

MongoDB Docker образ

К сожалению, нет официального образа для MongoDB. Доступно однако образы сообщества Docker. Как с любым неофициальным образом, рекомендую вам просканировать образы на проблемы и проанализировать Dockerfile.

Dockerfile и скрипты сборки могут быть найдены MongoDB образы в Docker сообщества.

Настройка MongoDB Docker

Скаченый образ предоставляет несколько переменных используемых для настройки базы данных.

MONGO_INITDB_ROOT_USERNAME
MONGO_INITDB_ROOT_PASSWORD
MONGO_INITDB_DATABASE

Первые два используются для логина и пароля администратора сервера. В основном для MongoDB достаточно задать два параметра.

Если MONGO_INITDB_ROOT_USERNAME и MONGO_INITDB_ROOT_PASSWORD не заданы значениями по-умолчанию, любой кто подключается к бд имеет полный доступ.

Secrets

Secrets предоставляет хранилище для безопасного хранения чувствительной информации в Kubernetes. Данные хранятся как секреты зашифрованные в base64, для сокрытия данных когда отображается на экране, и хранится зашифрованно на ETCD базе данных используя Kubernetes. TheДва twoконфигурационных configurationзначение valuesкоторые thatвыдаются standoutкак asдополнительная requiring extra protection areзащита MONGO_INITDB_ROOT_USERNAME andи MONGO_INITDB_ROOT_PASSWORD.

ToЧтобы create aсоздать Kubernetes secretсекрет for theдля MongoDB rootсупер userпользователя andи passwordпароль, youвы couldдолжны runзапустить theследующую following kubectl create command.команду.

kubectl create secret generic mongodb \
--from-literal="root" \
--from-literal='my-super-secret-password'

Alternatively,Как aвариант, Secret manifestманифест(secreat.yaml) canможет beбыть writtenсоздать andи appliedприменен toдля create the MongoDB secrets.создания.

Манифест Secret manifestsне shouldдолжен notхранится beв storedgit, inособенно versionв controlтой systems,же especiallyдиректории inгде theдругие same repository as your other manifests.манифесты. Kubernetes storesхранит secretsсекреты asкак base64 encodedзашифрованная strings.строка. SecretМанифест manifestsпозволяет giveвыбирать youнаписание theзначения optionсекрета: ofкак writingобычная theстрока secret value as a regular string or aили base64 encodedзашифрованная string.строка. ToЧтобы preventпредотвратить exposureвозможность fromувидеть someoneпароль lookingчерез overваше yourплечё shoulderесть itпредложение isвсегда advisableкодировать toпароль alwaysв base64.

Для того. чтобы закодировать пароль в строку используюя base64 encodeиспользуйте passwords.следющую команду:

To base64 encode a password string use the base64 command available on Linux and OSX.

echo -n 'my-super-secret-password' | base64
| Output
bXktc3VwZXItc2VjcmV0LXBhc3N3b3Jk
Create
a

Создайте newновый fileфайл namedс именем mongodb-secrets.yaml andи addдобавьте theв followingнего contents.следующеее Secretsсодеражние. canСекреты beможет storedбыть asсохранен в манифесте как data orили stringData. inВсе theданные Secretв manifest.ключе Alldata dataдолжны valuesбыть underзашифрованны theкак database64. keyЗначения mustлежащие beв base64ключе encoded.stringData Valuesне storedтребуют underшифрования the optional stringData key do not require being base64 encoded.base64.

apiVersion: v1
kind: Secret
metadata:
  name: mongodb-secret
data:
  MONGO_INITDB_ROOT_PASSWORD: bXktc3VwZXItc2VjcmV0LXBhc3N3b3Jk
stringData:
  MONGO_INITDB_ROOT_USERNAME: myroot

ApplyПрименяем toманифест manifestчтобы toсоздать createресурс the resource in yourв Kubernetes cluster.кластере.

kubectl apply -f mongodb-secrets.yaml

MongoDB Deployment Manifestманифест

A

Deployemnt deploymentописывает describesжелаемое aсостояние desiredкоторое state to be enforced by theсоздаст Deployment Controller. WhenКогда theсостояние stateдеплойментя ofотойдет aот deployment shifts away from the desired state, theжелаемого, Deployment Controller willпроизведет performдействия actionsчтобы toвернуть bringжелаемое the state back.состояние.

OneОдин exampleиз ofпримеров maintainingуправления stateсостоянием isэто ensuringубедится aв setколичестве numberреплик ofработающих replicaподов. PodsЕсли isпод running.деплоймента If a Deployment Pod fails theупадет Deployment Controller willзаменит replaceупавший the failed Pod.под.

UpdatesОбновления andи Rollbacks:откаты: WhenКогда aшаблон Podпода templateобновлен is updated in aв Deployment resource, theресурсе, Deployment Controller willразверент deployобновленные updatedподы Podsпрежде beforeчем removingудалять theстарые. olderНовые Pods.поды Theне newзаменят podsстарые willдо notтех replaceпор, theпока olderне onesзапустятся unlessсо theздоровым start with a health state.состояниме.

CreateСоздадим aновый new file namedфайл mongodb-deployment.yaml andи addдобавим theследующее following contents.содержание.

apiVersion: app/v1
kind: Deployment
metadata:
  name: mongodb
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mongodb
  template:
    metadata:
      labels:
        app: mongodb
    spec:
      containers:
      - name: mongodb
        image: mongodb:3.6.19-xenial
        ports:
          containerPort: 27017

TheПример exampleвыше aboveразвернет willодну deploy a single replica of aреплику MongoDB instance.сущности. TheБазовый baseобраз imageиспользует will use the DockerDocket Community MongoDB imagev3.6.19 atоснованные version 3.6.19, which is based onна Ubuntu Xenial.

ApplyПрименим theманифест manifestчтобы toсоздать createдеплоймент theресуср deployment resource inв Kubernetes.

kubectl apply -f mongodb-deployment.yaml

CustomСвой MongoDB Configконфиг Fileфайл

OurНаш MongoDB podпод usesиспользует theстандартные defaultнастройки configurationдля forвновь aсозданного newlyсервера. installedТолько server.2 Theпараметра onlyсконфигурированны twoэто itemsлогин configuredи thus far are the username and password.пароль.

There a are plenty of other configurations options in aВ MongoDB server.сервере However,есть theseмножество optionsнастроеке. areОднако, configuredэти fromнастройки withinзадаются aв mongodb.conf file.файле.

CreateСоздаем ConfigMap

ToЧтобы useиспользовать a mongodb.conf fileфайл withв yourнашем MongoDBэкземпляре instance onв Kubernetes youвы mustдолжны createсоздать aфайл fileи andсохранить storeего itкак asconfigMap a configMap item.сущность.

TheВозьмем followingза isпример anфайл example of a mongodb.conf file.:

systemLog:
   destination: file
   path: "/var/log/mongodb/mongod.log"
   logAppend: true
storage:
   journal:
      enabled: true
processManagement:
   fork: true
net:
   bindIp: 127.0.0.1
   port: 27017
setParameter:
   enableLocalhostAuthBypass: false
To
create

Чтобы aсоздать configMap itemсущность ofиз the mongodb.conf file,файла, runзапустите theKubernetes followingкоманду. kubectlПример command.ниже Theсоздаст followingconfigMap exampleс createименем amongodb, ConfigMapесли namedон mongodb,еще ifне itсуществует, doesn’tи alreadyдобавить exits, and adds the mongodb.conf fileв toсщуность aпод itemназванием named conf.conf.

kubectl create configMap mongodb-config-file --from-file=conf=mongodb.conf

MountМонтирование mongodb.conf fileфайла

TheСамый simplistпростой wayспособ ofиспользования injectingконфигурационного theфайла configuration file into yourв MongoDB Podпод isэто byмонтированием mountingфайла theв fileкачестве asvolume. aПосле volume.этого Theконфигурационный configurationфайл fileбудет willдоступен thenкак be avaibable as file to theфайл MongoDB serviceсервиса whenкогда itsзапустится container starts.контейнер.

ToДля mountмонтирования theфайла configurationв fileкачестве asvolulme aнам volumeнужно weобновить needнаш toDeployemtn update our Deployment manifest.манифест.

apiVersion: app/v1
kind: Deployment
metadata:
  name: mongodb
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mongodb
  template:
    metadata:
      labels:
        app: mongodb
    spec:
      containers:
      - name: mongodb
        image: mongodb:3.6.19-xenial
        ports:
          containerPort: 27017
        volumeMounts:
        - name: mongodb-configuration-file
          mountPath: /etc/mongod.conf
          readOnly: true
    volumes:
    - name: mongodb-configuration-file
      configMap:
        name: mongodb-config-file

Постоянное хранилище Persistent StorageVolumes

ContainersКонтейнеры areнедолговечны ephemeralпо byопределению. design.Любое Anyсостояние stateконтенейра changesбудет toпотеряно theпосле containerперезапуска. willДля beбаз lostданных when the container stops. For a database server likeкак MongoDB, thisэто meansзначит yourчто entireвся databaseваша willбаза beданных wiped.будет стерта.

Persistent Volumes может быть смонтированно в Pod позволяя сохранять данные вне зависимости от наличия контенера. Чтобы добавить Persistent Volumes в контейнер в Kubernetes нужно создать Persistent Volumes canClaim beи mountedзатем toсмонтировать avolume Podк allowing data to persist beyond the life of a container. To add persistent volumes to a container in Kubernetes you will need to create a Persistent Volume Claim and then mount the volume to a Deployment.Deployment.

CreateСоздадим aфайл fileпод namedназванием mongodb-pvc.yaml andи addдобавим theв following contents.него:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mongodb-pv-claim
  labels:
    app: mongodb
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

The volumeVolume claim willсоздаст createхранилие aв writableкоторое storageможно volume,будет provisionedчто-то byписать yourразмером cloudв provider, with a 1GB size.1GB.

ApplyПрименим itего toк theнашему clusterKuberentes using the kubectl apply command.кластеру.

kubectl apply -f mongodb-pvc.yaml
To
mount

Чтобы theсмонтировать раздел нам нужно обновить наш deployemtn манифест. volume weнужно needбоавить toв updatetemplate ourключ deploymentнашего manifest.манифеста, Aа volumevolumeMount needsв toключ beконтенера, addedчтобы toсмонтировать the template key in our manifest, and a volumeMount with the container key to mount the volume. We’ve highlighted both below.раздел.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mongodb
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mongodb
  template:
    metadata:
      labels:
        app: mongodb
    spec:
      containers:
      - name: mongodb
        image: mongo:4.4.0-bionic
        ports:
          - containerPort: 27017
        envFrom:
        - secretRef:
            name: mongodb-secret
        volumeMounts:
        - name: mongodb-configuration-file
          mountPath: /etc/mongod.conf
          readOnly: true
        - name: mongodb-persistent-storage
          mountPath: /data/db
      volumes:
      - name: mongodb-persistent-storage
        persistentVolumeClaim:
          claimName: mongodb-pv-claim
      - name: mongodb-configuration-file
        configMap:
          name: mongodb-config-file

ApplyПрименим yourновый deploymentдеплоймент manifest toчтобы updateобновить anсущействующee existingили deploymentсоздать orновое to create one.развертывание.

kubectl apply -f mongodb-deployment.yaml

ExposingВыставление Serviceсервисов

SoМы farразвернули we’veодин deployedпод aMongoDB. singleВыставление Podпода ofв aвиде MongoDBсервиса instance.настоятельно Whileне thisрекомендуется singleвне podтестирования canили beразработки. exposedПоды asнедолговечны aи serviceкак itтолько isони stronglyостановятся discouraged,их outsideсостояние ofпотеряется, testingв andтом development.числе Podsназначенный areip ephemeral and once they stop their state is lost, which includes the assigned IP address.адрес.

InternalВнустренний Serviceсервис.

AnВнутренний internalсервис serviceэто isсервис aкоторый serviceдоступен theтолько isвнутри onlyкластера accessibleKubernetes. fromЭто withinстандартное theповдение Kubernetesсервиса. cluster.Для Thisбазы isданных theсервер defaultи behavoirдругих ofсистемы aэто service.лучший Forвариант database server and other backend systems this is the most likely service configuration.настройки.

CreateСоздадим aновый newсервис serviceдля for the MongoDB instance.MongoDB.

apiVersion: v1
kind: Service
metadata:
  name: mongodb
spec:
  selector:
    app: mongodb
  ports:
  - protocol: TCP
    port: 27017

ApplyПрименим the manifest to the Kubernetes cluster to create the service resource.манифест:

kubectl apply -f mongodb-service.yaml

Backing Up MongoDB

ItВсё goesчто withoutбыло sayingсказано thatвыше protectingсовершенно yourне isсодержит oneшагов ofотвечающих theза mostбезопасность importantсистемы. thingsЕсть youнесколько willметодов needдля to do. There are several methods to backing up yourбэкапирования MongoDB databases inв Kubernetes, butно thisэта guideинструкция willсфокусируется focusна onсоздании schedulingрасписания it as an automated process usingв Kubernetes CronJobs.

в

Toкачествет learn how to manually backup a MongoDB server running in Kubernetes, read our How to backup and restore MongoDB on Kubernetes.CronJob.

CronJob

A CronJob isэто aрасписание scheduled,контейнеризированных containerized job.работ.

A CronJob backupбэка forдля MongoDB willбудет performделать the following:следующее:

Run

  • Запустит MongoDB containerконтейнер
    • image
  • Смонтирует Mountраздел volume used byиспользуемый MongoDB
    • instance
  • Выполнит Executeкоманду mongodump command
    • to
  • Скопирует dump databaseв Copyкорзину dumpхранилища, toк a storage bucket, such as aпримеру Google Cloud Storage Bucket.

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: mongodb-backup
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: mongodb-backup
            image: mongo:4.4.0-bionic
            args:
            - "/bin/sh"
            - "-c"
            - "/usr/bin/mongodump -u $MONGO_INITDB_ROOT_USERNAME -p $MONGO_INITDB_ROOT_PASSWORD -o /tmp/backup -h mongodb"
            - "tar cvzf mongodb-backup.tar.gz /tmp/backup"
            #- gsutil cp mongodb-backup.tar.gz gs://my-project/backups/mongodb-backup.tar.gz
            envFrom:
            - secretRef:
                name: mongodb-secret
            volumeMounts:
            - name: mongodb-persistent-storage
              mountPath: /data/db
          restartPolicy: OnFailure
          volumes:
          - name: mongodb-persistent-storage
            persistentVolumeClaim:
              claimName: mongodb-pv-claim

AdministeringУпралвение MongoDB in Kubernetes

WhileТак aкак MongoDB likelyне shouldn’tдолжно beбыть exposedдоступно outsideвне ofнашего theкластера. KuberentesОператор cluster,до anсих operatorпор isможет stillподключиться ableк to make a network connection with it.нему.

PortПеренапралвение Forwardпортов.

TheПеренаправление портов с помощью kubectl port-forwardпозволяет commandнам allowsсоздать usпроксированное toподключение createк aвашей proxiedмашине connection for your client machine to theв Kubernetes service.сервисе. ForДля MongoDB thisто meansзначит weмы areможем able to make aсоздать mongodb clientподключение connectionк toнашему our server.серверу.

kubectl port-forward mongodb-service 27017 &
| Output



Forwarding from 127.0.0.1:27017 -> 27017
Forwarding from [::1]:27017 -> 27017
With
the

С portпомощью forwardedполученного from our local machine to theпорта MongoDB serviceна weнашей canлокальной useмашине, theмы можем использовать mongo clientклиента toдля conenct.подключения.

mongo -u <root-username> -p <root-password>
| Output



MongoDB shell version v4.2.0
connecting to: mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb
Handling connection for 27017
Implicit session: session { "id" : UUID("feb9a859-43eb-4cb3-bdd9-ef76690cbb92") }
MongoDB server version: 3.6.19
WARNING: shell and server versions do not match
Server has startup warnings: 
2020-08-24T03:21:23.861+0000 I STORAGE  [initandlisten] 
2020-08-24T03:21:23.861+0000 I STORAGE  [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2020-08-24T03:21:23.861+0000 I STORAGE  [initandlisten] **          See http://dochub.mongodb.org/core/prodnotes-filesystem


>

Interactive

Интерактивная Containerконсоль Shell

в контейнере

Alternatively,Как anзамена, interactiveможно shellоткрыть canинтерактивную beконсоль openedвнутри into the runningрабочего MongoDB container.контейнера. YouДля willэтого needнужно the name of yourназвание MongoDB podпода inчтобы orderзайти toв shell into it.него.

kubectl get pods
| Output



NAME                       READY   STATUS    RESTARTS   AGE
mongodb-7cfbc6f555-t97c4   1/1     Running   0          12m
We
are

Так onlyкак runningу aнас singleтолько replicaодна andреплика itsи nameеё isимя mongodb-7cfbc6f555-t97c4. NowТеперь thatзная weимя haveнашего theпода Pod’sможно nameподключиться weк can shell into it.нему.

kubectl exec -it mongodb-7cfbc6f555-t97c4 /bin/bash
| Output



root@mongodb-7cfbc6f555-t97c4:/# 
When
the

Когда interactiveзапустится shell forв theконтейнере containerмы createdможем we can manageуправлять MongoDB usingипользую Mongo’sего interactiveвнутренную shell.консоль.

mongo -u $MONGO_INITDB_ROOT_USERNAME -p $MONGO_INITDB_ROOT_PASSWORD

ConclusionВ завершении

InВ thisэтой guideинструкции weмы coveredобсудили howкак to deployразворачивать MongoDB onв Kubernetes andи manageуправлять it.им. YouНаучились learnedкак howбезопасно toхранить securelyданные storeдля credentialsдоступа forк yourвашей database,бд. asКак wellнастроить asсервис howдля toдоступности exposeего itвнутри to other services running within your cluster.кластера.

OneОдна ofиз theважных moreтем importantэто topicsбэкапирование, isкоторую backups,мы whichразвернули weв coveredкачесте as an automated process using CronJobs.CronJob.

Back to top