search

cytopia / devilbox

A modern Docker LAMP stack and MEAN stack for local development
http://devilbox.org
MIT License
4.37k stars 652 forks source link

How do not use suffix? #409

Closed josevavia closed 5 years ago

josevavia commented 5 years ago

ISSUE TYPE

SUMMARY

It is possible to modify the vhost_gen or the internal setup to get the next behavior?:

Goal

I know that its a weird setup but I need it for compatibility with a lot of projects based in xampp/lampp structure and a lot of developers using xampp with this setup. We are migrating to devilbox but we need a transition time and we want to make minimal changes in the code of the existing projects.

I am triying to understand the vhost_gen templates but it exceeds my knowledge

Of course, thanks a lot for this great project

cytopia commented 5 years ago

I know that its a weird setup but I need it for compatibility with a lot of projects based in xampp/lampp structure and a lot of developers using xampp with this setup.

Are those projects on production also behind a sub-directory on a single domain?

Anyway, this is still a good objection and I will have a look into this. Can't promise atm, but will definitely give it a try.

josevavia commented 5 years ago

I know that its a weird setup but I need it for compatibility with a lot of projects based in xampp/lampp structure and a lot of developers using xampp with this setup.

Are those projects on production also behind a sub-directory on a single domain?

Not on a single domain, but yes in sub-directory structure. Anyway this is not a production related question, is only for the development environment. The main problem is that all of our development environment is depending on a structure like http://localhost/[folder_name].

We have redirects (only for dev environment) to routes like http://localhost/project_name, and specially a lot of projects using apis in other projects, so http://localhost/project_1 is using http://localhost/project_2 and this route is hardcoded as endpoint.

Also, using this structure allows us to access the teammate environments without modifiying /etc/hosts... If mine is http://localhost/project_1, then I know that my teammate is http://192.168.0.52/project_1

There are occasions when I want my project_1 using the project_2 API version of a teammate, so I setup the endpoint to http://192.168.0.52/project_2 and everything works.

If we use devilbox "as is", I am think on using different suffix for any developer (http://project_1.person1 vs http://project_1.person2) but it requires us to modify /etc/hosts in each workstation...

Thanks for your reply, you are very kind

cytopia commented 5 years ago

but it requires us to modify /etc/hosts in each workstation...

Actually not, you could simply use the bundled Auto-DNS feature to have the DNS records automatically: https://devilbox.readthedocs.io/en/latest/intermediate/setup-auto-dns.html

Then you just add EXTRA_HOSTS for all other developers into your configuration: https://devilbox.readthedocs.io/en/latest/configuration-files/env-file.html#extra-hosts

josevavia commented 5 years ago

but it requires us to modify /etc/hosts in each workstation...

Actually not, you could simply use the bundled Auto-DNS feature to have the DNS records automatically: https://devilbox.readthedocs.io/en/latest/intermediate/setup-auto-dns.html

Then you just add EXTRA_HOSTS for all other developers into your configuration: https://devilbox.readthedocs.io/en/latest/configuration-files/env-file.html#extra-hosts

Only one problem with that (sorry!). Not all the users accesing this endpoints are using devilbox, maybe a "non-developer" user wants to view the progress in a project so now, he access http://192.168.0.52/project_2 for example. As far as I know, http://project_2.person will no be accessible if there is no devilbox working in the host.

cytopia commented 5 years ago

Not all the users accesing this endpoints are using devilbox, maybe a "non-developer" user wants to view the progress in a project so now, he access http://192.168.0.52/project_2 for example

Also have a look here which might or might not be interesting for your use case: https://devilbox.readthedocs.io/en/latest/corporate-usage/shared-devilbox-server-in-lan.html

I let you know as soon as there is progress on this issue

cytopia commented 5 years ago

So currently I am a bit stuck on this one.

As I am also about to integrate having multiple PHP versions running at the same time I figured that both will interfere a bit.

Multiple PHP versions will allow for the following DNS scheme:

Project name: test01:

The intranet will only ever be served by the default version and only projects will make use of different versions by different DNS suffixes as shown above.

When it comes to serving projects via localhost, 127.0.0.1 or <IP>, I don't have a way to provide different versions, but only the current. This might lead to an inconsistent behaviour.

Any thoughts on this?

josevavia commented 5 years ago

I was reading Run multiply PHP versions and in my opinion (and for my personal use cases) I dont need to test a project in different php versions, instead of setup a different php version for specific projects.

I my case, we have a lot of codeigniter based projects (where doc_root is ., and running in php5), and a few of laravel projects (where doc_root is public, and running in php7).

It would be awesome to have the next config:

Dir Doc root Php version Url
/home/user/projects/codeginiter1 . php5.6 http://localhost/codeigniter1
/home/user/projects/codeginiter2 . php5.6 http://localhost/codeigniter2
/home/user/projects/codeginiter3 . php5.6 http://localhost/codeigniter3
/home/user/projects/laravel1 public php7 http://localhost/laravel1

That is a similar behaviour to shared hostings (cpanel...), where you can setup the document root and php version per project.

As an idea, with that config maybe you will be able to test project codeigniter1 with php7 in the url https://localhost.php7/codeigniter

cytopia commented 5 years ago

Having custom doc roots is already included:

That is a similar behaviour to shared hostings (cpanel...), where you can setup the document root and php version per project.

I can't make a relation between PHP versions and docroot atm, as this is a global config. You can however as the first link above shows use any doc root provided by the framework and then just symlink it to the globally defined docroot (2nd link)

Once multiple PHP container are already up and running, they should be able to be used by any project anyway and not setting a fixed limitation on this.

As the Devilbox intranet is served by the default vhost anyway, I could imagine that any project served via localhost domains is then also served by the default PHP container (whatever is set in .env)

science695 commented 5 years ago

@cytopia would it work for him to add his projects to the default intranet with html/javascript or even htaccess redirect rules?

i.e.(apache example): ./.devilbox/www/htdocs/.htaccess:

RewriteEngine On
RewriteRule "^/project_1/(.*)$" "http://project_1.loc/$1
RewriteRule "^/project_2/(.*)$" "http://project_2.loc/$1
...
cytopia commented 5 years ago

I suppose htaccess rules could be working. Javascript on the other hand won't as it is interpreted by the client which needs to be able to resolve the domain correctly. But htaccess is a good catch here for a third solution

josevavia commented 5 years ago

Ok, after giving a lot of thought to the subject, in the end I opted for the following solution:

So we get to use devilbox "as is" and we only have the problem of the old code with "localhost" hardcoded, but it is a little problem compared to the benefits of using devilbox

Thanks for the ideas and the help, it has helped me a lot to understand better how everything works.

cytopia commented 5 years ago

Glad to hear that it finally works for you

cytopia commented 5 years ago

@josevavia As no further issue has arised with your setup, I will close this one.