Replies: 6 comments 7 replies
-
|
As I understand it, this will mean that vestacp can only be installed on dedicated servers or virtual machines, it cannot be installed on openvz or lxc or in any container? |
Beta Was this translation helpful? Give feedback.
-
|
@Skamasle we will have to test openvz, but you can run an LXC container inside an LXC container. It works quite well on a DigitalOcean droplet, Linode/Akamai, or an EC2 instance on AWS. It should also work well inside most VM engines. |
Beta Was this translation helpful? Give feedback.
-
|
A good development plan. I think this is the right decision. |
Beta Was this translation helpful? Give feedback.
-
|
just small question this means "running sites inside containers" if someone site got hacked no harm for other sites on the server right? |
Beta Was this translation helpful? Give feedback.
-
|
@t4ba correct, if a individual site gets hacked, the hackers would not be able to access anything outside of that container. |
Beta Was this translation helpful? Give feedback.
-
|
good, also web terminal will be a good thing to use only commands like composer |
Beta Was this translation helpful? Give feedback.
-
|
@t4ba definitely, you will be able to log inside the container and run commands like composer. Alternatively we also plan to allow a build command that installs composer, runs the commands, and deploys the site automatically. |
Beta Was this translation helpful? Give feedback.
-
|
would be cool if you guys can give support for fossbilling :) |
Beta Was this translation helpful? Give feedback.
-
|
I just read "Vesta 2.0: Coming Soon" and I noticed that it doesn't mention anything about the API. Will an API be present in 2.0? |
Beta Was this translation helpful? Give feedback.
-
|
@alekzandrgw Yes, the Core of Vesta will use an API for the web admin to talk to it, and for third party systems and integrations to talk to Vesta itself. The API will be considerably different, but we haven't finished defining the available calls. Please let me know if you have any specific use cases/actions/calls that you would like to ensure we add to the new version of Vesta. |
Beta Was this translation helpful? Give feedback.
-
|
Exciting news, thank you. I would appreciate if sending backups to Dropbox would still work, as described here. Thanks! https://forum.vestacp.com/viewtopic.php?t=14123 |
Beta Was this translation helpful? Give feedback.
-
|
@outrolled Have you decided on a mail stack yet? If not may I highly suggest Stalwart Mail Stack Supports everything and has a fantastic API so it could integrate well with VestaCP (IMAP, SMTP, Spam Filtering, Mail Sieve, AutoDiscover, AutoConfig) https://stalw.art/ For DNS may I suggest PowerDNS as this is Database Driven and Scalable with a great API. Thank you for continuing to develop VestaCP its been a great piece of software. |
Beta Was this translation helpful? Give feedback.
-
|
Hey @outrolled is there a git repo to follow development for the new VestaCP 2.0? Super excited about it and deff was the right approach to use LXC. |
Beta Was this translation helpful? Give feedback.
-
Firstly I wanted to thank all contributors and the Vesta community for the hard work, active forks, and effort invested into Vesta and its many derivative works.
I spent the last few weeks reviewing and thinking about the future of VestaCP, especially around technical and system architecture.
I would like to provide an update on the direction that we are planning on moving with Vesta 2.0.
Current Forks: We will not follow the same path
The beauty of GPLv3 is that we could re-incorporate work from other forks such as Hestia back into Vesta. This would be the easiest path forward, as we could pick the best work whilst accelerating the process of getting Vesta back into top shape. This is a good idea in principle, however we will not follow this path as I believe that we need to re-think the full system architecture for Vesta to be relevant in the future (and future proof).
Everything inside containers
I did a lot of system architecture design and compliance work, and I believe that Vesta will not survive the future if we are not running each site inside a separate container. The current approach of multiple users, sites, etc inside the same instance is too vulnerable security-wise (I am also confident that auditors and even some countries will require software to run inside containers for compliance purposes).
With the above in mind, our goal will be to create container templates that users can pick and deploy. For example, you will be able to create a site, select a cloud-init template (e.g. PHP-PFM + NGINX, or Node.js) and Vesta will create an LXC container with the correct port forwarding etc. The goal here is for the community to be empowered to create container cloud-init templates to deploy generic systems, or complete applications (e.g. WordPress, Directus CMS, etc).
Why not Docker?
Developers love Docker, however LXC is better suited at creating persistent containers that will provide the same level of functionality that Vesta currently offers. The beauty of this approach is that anyone can create a container template to run docker containers (if that is what you really want).
Cloud-init template marketplace
If there is enough demand, we will be able to add a cloud-init marketplace. This would allow a larger volume of container templates to be distributed and maintained. This would also help ensure we have the widest range of compatible images/OS/applications that can run inside Vesta.
Compatibility
Given the community input, we will focus on making VestaCP compatible with all operating systems that can run LXC and LXD (Linux Containers). We will focus on Ubuntu as the core supported system, but we will build on an architecture that can run inside any OS that can create our container "templates".
The Forwarding Proxy and SSL
Given that everything runs inside a container, we will need a forwarding proxy or load balancer running outside of each individual container to send traffic to the correct IP/Port based on hostname. This can be NGINX or a custom binary (we are thinking about a no dependency Go (Golang) binary for the job to increase OS compatibility). This binary should be able to forward thousands of requests a second, negotiate SSL certificates with Lets Encrypt, and possibly push logs somewhere.
Web Application Firewall (WAF)
I own a WAF software company, and I am thinking about bundling it for free with Vesta instances. Given this is not part of the core product, it can be an optional plugin. This would help improve the security of Vesta powered sites without relying on third party WAFs.
Why Vesta 2.0?
Vesta never quite got to version 1.0, however the last version that became public was 1 dot something. Given that we are starting anew, and that v1 was (somewhat) out, we decided to refer to it as Vesta 2.0.
What is the timeline
There is a lot of system architecture and planning that we still need to complete, especially around how we can migrate old installs, move code, databases, configuration etc. With this in mind, we are aiming to have a release candidate in around 3 months. We can't promise any timeframes at this stage, but we will make the maximum effort we can.
What will Vesta itself be built on?
Please give us your opinion. Using LXC/LXD will help us simplify the application a lot, however we will still need a VestaCP "software" that can orchestrate everything. PHP + Bash is a good candidate, however we are also considering Go, or Go + Bash, but it depends on the community interest in supporting the development process.
Please let me know if you are interested in contributing, and what tech stack you suggest we use.
Beta Was this translation helpful? Give feedback.
All reactions