I accidentally deleted my most important Docker container—here’s how I brought it back from the dead

I accidentally deleted my most important Docker container—here’s how I brought it back from the dead


I like to run applications in Docker. While I’ve explored the subject a few times, there’s one containerized application I always return to: FreshRSS. But I messed up my installation. Here’s how I brought it back from the dead with some planning and foresight.

A quick note about what containers are

Revisiting the terminology for folks new to the hobby

I accidentally deleted my most important Docker container—here’s how I brought it back from the dead Credit: David J. Buck/How-To Geek

Following some recent feedback from a reader, I would like to take a moment to talk about what containers actually are. I agree with what they had to say, especially in regard to getting the terminology right.

In my last few Docker-adjacent articles, I referred to the isolated, self-hosted apps I use with Docker as “containers.” I continue to do so when I discuss how I use them. I’m not a developer, but I do use containerized applications both professionally and for hobby projects.

While this is accepted shorthand, I should clarify that Docker is a brand name and a container is an isolated environment that contains an application and the dependencies it needs to work properly.

Containers are not the applications themselves, but many of us who use them often refer to the entire thing as a “container.”

This can be very confusing for anyone getting into working with containerized applications.

But the reason I prefer running these apps as containers comes down to being able to run them on any machine I use, the fact that I can isolate them, and the ability to use “rollback” features. If something messes up on one application I use frequently, it’s sometimes easier to fix it if it’s in a container. Containers are also highly configurable and offer a lot of control for these applications.

This came in handy with my FreshRSS instance when I accidentally purged it from my system.


Illustration of the Docker logo, featuring a stylized whale carrying containers and a NAS server.


Optimize Your Docker Updates With This Trick

Are you still manually updating your Docker containers?

Misadventures with Docker storage management

Disk storage analysis.

I royally screwed up a few weeks ago. I noticed my hard drive space was rapidly shrinking. Part of this is due to how Docker works. You have images, which are the instructions for the container that has everything you need to run the program. The image is the template where you’ll find the dependencies, libraries, systems tools, and code for the app itself.

Then there’s the container, which, according to Docker itself, is “a runnable instance of an image.”

When I noticed the storage issues, I thought Docker might be the culprit simply because that’s what I had been experimenting with almost exclusively on this machine for a solid week. So I cleared my cache and looked at exactly how much space my images, containers, and volumes were taking up.

I ran docker system df command to check, and sure enough, there was quite a bit of space being taken up in the build cache and I had several inactive Images and Containers.

Today, I know the right way to perform maintenance on is by using tools like docker image prune --all and docker builder prune to clear the build cache. If you only use the prune command without the –all attached to it, it removes dangling images. Appending the –all command removes all images that don’t have at least one container associated with them.

A listing of how much space docker images, containers, and volumes are taking up on a hard drive Credit: David J. Buck/How-To Geek

As of this writing, I had 10 total images, 7 of which are active on my system. I have 7 containers I’m currently using. So I run these commands again to clean things up. Everything works properly.

When I was going through different commands before to “clean up” my drive, however, I took a more aggressive approach. Long story short, I blindly used a command that had rm on FreshRSS container. It wasn’t exactly a shining moment in my Docker journey.

A listing of docker images and containers after cleaning. Credit: David J. Buck/How-To Geek

By not fully understanding the destructive power of the rm command, despite my enthusiasm for the subject, I mistakenly purged my entire FreshRSS installation. Thankfully, I learned from my mistake and won’t do that again unless I actually do want to permanently remove a container.

Fortunately, I had a backup plan to get FreshRSS back.

A mix of reinstalling things and importing a backup

I quickly learned that when you remove a Docker container, you can’t recover it. That particular instance is gone forever, lost to a black hole. It’s easy enough to make a new one, though.

When I couldn’t load it, I thought it had just stopped. Nope. My entire FreshRSS app was gone.

For the future, I did make a backup of the image and container just in case. But to get my current program back up and running, I ended up doing a fresh install, using the same process I used to get my RSS reader going in the first place. I chose to run it with Docker Compose this time around.

I had the foresight to export my original FreshRSS set-up as an OPML file, which I only did because I was experimenting with newsboat at the same time (OPML stands for Outline Processor Markup Language and is just a way to import/export and back up entire feeds).

After setting up my new FreshRSS image, I created a new user account. After that, I went to Subscription Management > Import/Export > Import and selected my OPML file. From there, FreshRSS imported all my RSS feeds from the previous instance.

I made a few adjustments to the configuration, like selecting Hide articles after reading and Clicking outside of article text area closes the article, which are improvements over my previous configuration.

To create the OPML file in the first place, it’s just a matter of going through Subscription Management > Import/Export > Export. Your OPML file will be downloaded as a ZIP file.

I always recommend making regular OPML file backups of your feeds. I do it every time I add or remove a news source (roughly every two weeks). I’m glad I got my FreshRSS instance back, and I still love using Docker to run containerized applications (I’m exploring a few more as we speak).

Now, it’s time to go back down my favorite rabbit holes.


A black and white cat sits next to a Motorola phone on a table, with Canta open on its display.


I removed Motorola’s bloatware from my phone, and now it feels brand-new again

I found a way to remove the bloatware from my budget Motorola phone. Here are the two apps I used and what I purged.


Listening to feedback and making mistakes is vital for any hobbyist

A clean install of Fresh RSS. Credit: David J. Buck/How-To Geek

When you’re experimenting with things as a hobby, there’s a lot of room for error. Fortunately, losing my FreshRSS feed wasn’t the end of the world.

But I broke a cardinal rule in a desperate attempt to clear up storage space: I executed commands without fully understanding them. Everyone makes mistakes, and I’m lucky it was for a personal thing and not important work.

So in the future, I’ll be very careful about the commands I execute when first diving into a new-to-me technology and, of course, continue to experiment with different applications using Docker well into the future.

docker desktop

OS

Windows, macOS, Linux

Brand

Docker




Source link

Leave a Reply

Your email address will not be published. Required fields are marked *