Comments (4)
They both have their advantages/disadvantages... :)
Obviously the "harder" way is the best way (why burden the image with unnecessary baggage if never used) but the "easier" way is also a valid-ish solution.
From the perspective of safety (and performance etc), it is best to not have any services that you do not use, and from the perspective of efficiency it is even better if they are not part of your stack in the first place.
So in summary: I'll take the "easy" solution but my suggestion would be to fully implement the creation of custom images. The current pojntfx/pojde
image is already close to 2.5GB!!!
EDIT: To add that, I took a look in your repo at the creation of a custom image, and indeed, given the current implementation, this will require quite some refactoring, thus indeed, this is the harder solution to this issue. But given that you've got so far already, this should be easy for you to refactor, I believe.
from pojde.
Absolutely! The easiest way would be a way for pojdectl
to enable/disable the relevant systemd/OpenRC services. The harder way would be to create different images for each config & their permutations - would the former be an OK solution to you? I.e. a dialog like such:
Select services to enable:
- Cockpit
- code-server
- ttyd
- noVNC
- JupyterLab
[OK]
from pojde.
Thanks for your points! I agree that making it fully modular would be a neat solution; pojde V1 actually did that, but I decided against it in the V2 rewrite - "compiling" said services takes a very long time, and shipping the monolithic image prevented the need to do some pretty advanced cache cleanups (pojde V2 has a ~950 MB base image, pojde V1 was pretty close to 10+ GB with some additions - shipping an entire OS in a container is not very efficient, but with pojde V2 the layers are re-used between all instances so there should no longer be duplication).
I'll go ahead and implement the "easy" way for now; Docker isn't really compatible with another solution (one would have to push all permutations of the services, as there is no way I know of at least which makes the images modular). Manual OverlayFS changes could be an option, but would probably be quite a bit of technical debt in the future.
from pojde.
@stratosgear I've prepared PR #12 which adds this feature:
To upgrade, run:
pojdectl upgrade-pojdectl
pojdectl apply <myinstance> <myfirstport> -f -u -r
from pojde.
Related Issues (5)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pojde.