I fucked up my DigitalOcean (DO) droplet or technically, I did not fuck up the droplet itself, but I deleted the SSH-key I needed to remote into it with the user account needed to have access needed.
With that said, it is the purpose for why I did the move to Kubernetes and why I had to find a way to get files out of my DO droplet.
Since I was not able to remote into my droplet as I used to, I had to use the Console Access through the web browser. There you get a terminal and most of the keys works fine, but with my keyboard layout (and I tried to use the keys where they are at an english keyboard as well), I was not able to fing "@" or "/". That is two symbols I needed a lot in the process. Luckily, it is able to copy/paste so I was able to type at my machine and paste it into the terminal.
How did I move the files from the DO droplet and into the block volume that was mounted to the Kubernetes pods?
First of all, I turned on remote login in the sharing section on my Mac. Be sure that the user you want to login with is in the allowed list (by default only the Administrator is in that list). Then I had to login to my router and setup a port forwarding on port 22 (SSH) to the IP-address of my MacBook Pro.
So far so good. Now I was ready to prepare and transfer the content folder of the Ghost blog from the DO droplet to my MacBook. From the console access web terminal, I logged in and changed the current directory to the content directory of my Ghost blog.
$ cd /var/www/myGhostBlog/content $ apt update # only if zip is not installed $ apt install zip # only if zip is not installed $ zip -r myblog.zip .
When I had the zip file that I wanted, I was ready to transfer the file to my computer and needed the public IP-address to my home network. Google can help with that as showed below.
To transfer the files, I used the SCP software that is part of the openssh-client install. That was already installed on my DO droplet, so no need to install that here.
$ scp ./myblog.zip email@example.com:/Users/myusername/Tmp/myblog.zip
Depending on how large that file is and how many images there is on the blog, it did not take that much time for me to download this.
Now what, how can I get the Ghost content files into the DO block volume?
I was thinking a little about that and in the beginning hoping that DO had any solution to transfer files into the volumes. It looks like they do not and the API do not have any endpoint that said that I could transfer files by writing a script. Then I started to thing that it is possible to exec script and commands inside a docker container, so it might be possible to remote into a pod as well. I know that a pod is just existing to run an image and that files stored inside a pod can be lost, but for the purpose of doing a transfer to a pod to place files in a mounted persisted volume, it works very nice.
The first thing that is needed is the name of the pod. That can be retrieved with the command
$ kubens blogns && kubectl get pods. The output of that command is the following.
$ kubectl get pods NAME READY STATUS RESTARTS AGE blog-7bc786dc98-wj6wd 1/1 Running 0 3h41m
That has to be the name of the pod where the persisted volume is mounted. Then I could continuing with my transfer.
$ kubectl exec -it blog-7bc786dc98-wj6wd -- /bin/bash $ apt-get update && apt-get install openssh-client # Not needed if exising, but did not exist on any of my pods $ apt install unzip # Not needed if exising, but did not exist on any of my pods $ cd /var/lib/ghost/content $ mkdir test && cd test $ scp firstname.lastname@example.org:/Users/username/Tmp/myblog.zip ./myblog.zip $ cd .. && rm -r images && mv test/images images # Repeat for the rest of the directories that need to be replaced $ exit # Exit the remote session in the pod $ kubectl -n blogns rollout restart deployment blog # Where "blog" is the deployment name
This is the exact steps that I used to move my files into the DO block storage and the restart the pod was needed for the running site to see the new files.
Happy coding and it is not recommended in general to delete the SSH-keys to a server. I know that I should have backed them up, but at least, now also the SSH-keys are stored in my 1Password account.