KB contents are lost when a docker container is restarted about kb HOT 16 CLOSED

from kb.

Ok I will try to address these problems one by one.
I am not a docker expert, but you should not compose everytime you need to use that instance of kb.
I mean, I think that @dilutedh2o meant a workflow like this:

Initialize the kb container:
docker-compose up -d
Use the kb from the container
docker exec kb_kb_1 kb list
docker exec kb_kb_1 kb add ...
docker exec kb_kb_1 kb view ...
Stop the docker container
docker stop kb_kb_1
Start the container
docker start kb_kb_1
Use kb again...

So when used like this, you are not going to lose anything, I don't think @dilutedh2o intended your
usage workflow when he/she wrote the dockerfile, so whenever you were re-composing you were losing
your data.

Now, as you addressed there are things with this docker that have to be solved.
In particular:

• We need to at least have vim and maybe also nano within the container
• We should deploy a docker container on dockerhub (I can think about that once we have a good dockerfile)

Do you agree? What do you think about this?

from kb.

from kb.

I agree we need an editor, but surely supplying an editor within the image is counter-"docker" -

"We need to at least have vim and maybe also nano within the container"

This probably won't suit Windows users who perhaps won't be familiar with vi/vim/nano etc and would rather notepad++, etc etc - Mac users also may want to use sublime etc etc....

I think (not being massively familiar with what is possible with Docker), but would it be better to configure an editor and use the editor from the deployed platform ?

from kb.

@alshapton I am not an expert too, but I don't think you can easily call a process from the host machine, since it is an isolated environment.
Anyway adding vim I don't think it would be counter-docker, but let's wait for the comment of @dilutedh2o. I think that for GNU/Linux users it would really be a plus (even if we had something more specific like kb-vim).
Also consider that generally these kind of docker solutions are mostly used by GNU/Linux users, because on Windows you have to mediate through a VM and so on.

from kb.

May wish to also loop dilutedh2o into the conversation as he introduced the docker feature. Volumes or Binds ... either works and anyone deploying docker would be able to modify docker-compose.yml appropriately. However, after doing more digging, I find that running inside of a docker container is problematic. Since a container is inherently text only, opening articles gets interesting, The function kb.filesystem.is_text_file() maps file "type" by extension. Running in a linux world I do not utilize extensions (and many folks do not), so a perfectly legitimate text file (like hostnames) is not a text file from the perspective of ...is_text_file(). OK, that is fine, but xdg-open will not run in a container (or I could not get one installed and running). The parts of the interface that I have exercised work in the container (I had to add vim to the image). Path forward?
…
On Thu, Sep 24, 2020 at 2:09 PM alshapton @.***> wrote: I think that we should be using Docker volumes - the persistent storage is outside of the Docker container and is managed by it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#33 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOIECFU22EJL2ERNXMO52TSHOROBANCNFSM4RYWT6PQ .

In response to your message, well a file without extension is a text file for kb. I am aware of the fact that extensions are more a Windows thing, but since this aims at being a cross-platform solution I had to keep them into account.
Also consider that extensions are useful in the *NIX world too, to associate applications to files as we said with xdg-open.

from kb.

Anyway adding vim I don't think it would be counter-docker, but let's wait for the comment of @dilutedh2o. I think that for GNU/Linux users it would really be a plus (even if we had something more specific like kb-vim).

Fair Point - agree.

Also consider that generally these kind of docker solutions are mostly used by GNU/Linux users, because on Windows you have to mediate through a VM and so on.

True - although at work we have Docker instances deployed on Azure and on AWS - but for small apps like kb at the moment you are correct - it IS probably only linux/Mac users who would use this sort of stuff.

from kb.

@alshapton I will do some research on this.
Anyway, if you send me your email address, I can add you to the development element (matrix) server of kb so that we can discuss about kb development. I can also add you to the AUTHORS list, since I see that you are contributing a lot to this project.

from kb.

Wow - thanks ! [email protected]

from kb.

from kb.

from kb.

@jakane your concerns are right!
But let's open another issue for the "file extension" task, what do you think? Would you mind opening an issue for the file extensions?

So that we can keep the docker issue and file extension issue separated.

from kb.

@jakane for what concerns the docker, we don't need to close the pull request, let's discuss some more.
I am interested in your "desired" workflow with docker.
How would you use it ?

from kb.

I will think about how to correctly word the "file extension" task and see if I can come up with a good issue description and some possible solutions.

I will also give more thought about how I would use Docker and kb ...

from kb.

@jakane thanks a lot for your help!

from kb.

Improved docker implementation - now awaiting release

from kb.