With loki-launcher, the entrypoint is loki-launcher itself, but there are 2 processes there

Not would like, it's just more natural to me

I will move my nodes from launcher whenever the team puts out an announcement to do so.

Running things in docker is a serious anti-pattern to me. You lose the advantages of shared libraries, you make system upgrades more complicated (because you now have to upgrade N docker images), everything takes considerably more memory because you don't get common code shared between processes, and you lose nice process management. People deploying docker images are doing it out of laziness because it's easier to just shove some static build with fixed dependencies into a docker container rather than having to deal with--gasp--dependencies.The only useful case I've ever come across for docker is in short-lived containers to do test builds (e.g. continuous integration).

Dockerization of services (of which AppImage and snapcraft is the same sort of garbage) is the worst thing that has ever happened to Linux software.

Software should be made to work robustly but dockerization encourages software devs to make it work very narrowly and then ship it in a docker as the only supported way to run it.

The one
As long as it unifies the deployment environment, It's useful to many people. 😉

It *doesn't* unify it: the vast majority of docker images have outdated software and libraries with security vulnerabilities in them because they don't get updated for all the things *inside* it other than the one developer binary.

@jagerman42 I use gentoo for all my pc, and when I try to install lokid, I don't want to deal with os differences issues, So, I'll containerize the lokid daemon, That's my initial reason running lokid within docker.

Later, we have loki-launcher, I extend my lokid image builder script, to also able to run as service node.

So, I can be sure, that if the image runs fine on my local machine, It'll definitely run fine on remote server.

That's why I personally prefer docker in the first place.

I don't like the swarm thing in docker, I feel it's over-complicated.

Yes, I know why people prefer it.

But it comes down to not fully understanding all the security implications of dockerization.

No one gives security a shit when only single "user" is maintaining the server. 😉

Yes; that is why I made the debs, because I am lazy too. But you can be lazy in a good way, or in a bad way, and docker is lazy in a bad way.

I don't understand anything

How do you get lokinet working in a docker container? I wouldn't think it would have access to tun devices, and the setcap within docker wouldn't do anything.

docker run --rm -d --name $name --cap-add net_bind_service --cap-add net_admin -p ...

I can't post image in this channel. 😞

So you give those capabilities to *everything* inside the container

Yet another reason docker sucks

I think that you would probably be better off running *each* of lokid/loki-ss/lokinet in its docker container. But then the problem is that they have to talk to each other, and docker makes *that* difficult.

Also, for people like me, I don't like anything java/ruby related to be installed on my host machine. I use docker to create utility images for this purpose.

@jagerman42 I don't like the docker idea that each service should have it's on container.

I'll move everything in a single container

There is no java/ruby/node in any of the software.

@jagerman42 I use gentoo, when you pull a, it needs b to be compiled.

The one
@jagerman42 I don't like the docker idea that each service should have it's on container.

This is not the docker way because it is not wasteful enough, you will be shunned by the docker community.

and sometimes, I meet app I must try, Then I fire up docker. my host is as clean as I always wished.

yea, I know my way of using docker is also discouraged by docker community.

What dependencies pull in java or ruby?

I forgot, Sometimes, I try some softwares, when I compile with gentoo, I'll tries to pull ruby, maybe for doc compilation as dependencies.

Have you tried using a linux container rather than docker?

It seems like it would fit the bill much better.

lxc is used for long time living thing. the docker can be considered deploy and throw

When you need an alternative linux env, lxc is perfect for this purpose.But deployment of lxc is not as easy as docker image, after docker image is built, You can just upload the image to http server, and cat http://example.com/path-to-image.tbz | docker load && docker run --name xxx image-id

SERVICE NODES SUMMARY:Current Block: 593,466Num of Running Nodes: 1,230Versions: 7.1.9 (78.94%), 7.1.10 (20.73%), 7.1.8 (0.33%), Service Node Stake Requirement: 16,805.741 LOKIBlock Reward for Service Node: 16.5 LOKIAvg daily Reward: 9.659 LOKIHours between rewards: 41h 0mTotally Contributed: 22,262,296 LOKI% of Circ. Supply: 45.137%Open for contribution: 8 pools (http://www.lokisn.com/status/awaiting_contribution)Decomissioned nodes: 1 (http://www.lokisn.com/status/decomissioned)

SERVICE NODES SUMMARY:Current Block: 593,483Num of Running Nodes: 1,231Versions: 7.1.9 (78.88%), 7.1.10 (20.80%), 7.1.8 (0.32%), Service Node Stake Requirement: 16,805.565 LOKIBlock Reward for Service Node: 16.5 LOKIAvg daily Reward: 9.651 LOKIHours between rewards: 41h 1mTotally Contributed: 22,279,102 LOKI% of Circ. Supply: 45.17%Open for contribution: 8 pools (http://www.lokisn.com/status/awaiting_contribution)Decomissioned nodes: 1 (http://www.lokisn.com/status/decomissioned)