Migrating Docker Compose to Kubernetes Volume Mount Isn't Supported

user_4171350 0
Viewed 1809

I am trying to change my existing deployment logic/switch to kubernetes (My server is in gcp and till now I used docker-compose to run my server.) So I decided to start by using kompose and generating services/deployments using my existing docker-compose file. After running 

kompose --file docker-compose.yml convert

#I got warnings indicating  Volume mount on the host "mypath" isn't supported - ignoring path on the host

After a little research I decided to use the command below to "fix" the issue

kompose convert --volumes hostPath

And what this command achieved is -> It replaced the persistent volume claims that were generated with the first command to the code below.

  volumeMounts:
        - mountPath: /path
          name: certbot-hostpath0
        - mountPath: /somepath
          name: certbot-hostpath1
        - mountPath: /someotherpath
          name: certbot-hostpath2

- hostPath:
          path: /path/certbot
        name: certbot-hostpath0
      - hostPath:
          path: /path/cert_challenge
        name: certbot-hostpath1
      - hostPath:
          path: /path/certs
        name: certbot-hostpath2

But since I am working in my local machine 

kubectl apply -f <output file>

results in The connection to the server localhost:8080 was refused - did you specify the right host or port? I didn't want to connect my local env with gcp just to generate the necessary files, is this a must? Or can I move this to startup-gcp etc

I feel like I am in the right direction but I need a confirmation that I am not messing something up.

1)I have only one compute engine(VM instance) and lots of data in my prod db. "How do I"/"do I need to" make sure I don't lose any data in db by doing something? 2)In startup-gcp after doing everything else (pruning docker images etc) I had a docker run command that makes use of docker/compose 1.13.0 up -d. How should I change it to switch to kubernetes? 3)Should I change anything in nginx.conf as it referenced to 2 different services in my docker-compose (I don't think I should since same services also exist in kubernetes generated yamls)

docker-compose kubernetes docker
1 Answers

You should consider using Persistent Volume Claims (PVCs). If your cluster is managed, in most cases it can automatically create the PersistentVolumes for you.

One way to create the Persistent Volume Claims corresponding to your docker compose files is using Move2Kube(https://github.com/konveyor/move2kube). You can download the release and place it in path and run :

move2kube translate -s <path to your docker compose files>

It will then interactively allow you configure PVCs.

If you had a specific cluster you are targeting, you can get the specific storage classes supported by that cluster using the below command in a terminal where you have set your kubernetes cluster as context for kubectl.

move2kube collect

Once you do collect, you will have a m2k_collect folder, which you can then place it in the folder where your docker compose files are. And when you run move2kube translate it will automatically ask you whether to target this specific cluster, and also option to choose the storage class from that cluster.

1)I have only one compute engine(VM instance) and lots of data in my prod db. "How do I"/"do I need to" make sure I don't lose any data in db by doing something?

Once the PVC is provisioned you can copy the data to the PVC by using kubectl cp command into a pod where the pvc is mounted.

2)In startup-gcp after doing everything else (pruning docker images etc) I had a docker run command that makes use of docker/compose 1.13.0 up -d. How should I change it to switch to kubernetes?

You can potentially change it to use helm chart. Move2Kube, during the interactive session, can help you create helm chart too. Once you have the helm chart, all you have to do is "helm upgrade -i

3)Should I change anything in nginx.conf as it referenced to 2 different services in my docker-compose (I don't think I should since same services also exist in kubernetes generated yamls)

If the services names are name in most cases it should work.

user_2063190
Related