I'm tasked with maintaining several web apps, all of them using the LAMP stack. Some of them run on PHP 5.6, some of them on PHP 7.0, some using Wordpress, some using Symfony... Ideally, I'd like to set up at home testing/development environments that are as identical possible as the production ones.
I've been investigating Docker (warning: total novice here!) to see if it suits my needs. I'll be working on Windows and Mac, and I'd like to have in my machine several LAMP environments, each of them with their version of PHP/MySQL/etc., isolated from each other and all of them running in the same VM (because otherwise I might as well just use what I'm familiar with and set up different VMs). Can Docker do this?
(Sorry if this sounds like a silly question: reading about Docker, my impression was that the container philosophy allowed you precisely to do what I described without wasting resources like with VMs, and yet, I haven't found any guides about running more than one LAMP environment at the same time).
Php Docker Stack
Php Docker stack to run Php Apps in Production and Development, using Docker Compose Services to run any Php version, Databases, Cache, Queues, Logs and much more...
From now on, no need to keep messing around the Operating System to have a full development stack ready to build our awesome Php Apps.
It can be included in each php project via composer:
https://packagist.org/packages/exadra37-docker/php-docker-stack
Or if you prefer you can clone it directly from here.
It comes with some default images for each service but is all configurable via .env, thus we can pass any docker image we want for any of the supported services in the docker compose file.
Php Docker Stack Services:
Http - Nginx, Apache, etc.
Php - Php-Fpm.
Database - Perconna, MariaDB, Mysql, etc.
Cache - Redis, MemCached, etc.
Logs - Logstash -> ElasticSearch <- Kibana.
Queue - Beenstalkd, RabbitMQ, ActiveMQ, Apache Kafka, etc.
Cron Jobs - Just to schedule cron jobs.
Dev CLI - Access to the container shell.
Database CLI - Like the awesome mycli propmt for mysql.
Cache CLI - Like the redis cli.
I was using it daily at my old job for development.
I am the author of it and I have some local enhancements that need to be polished and merged upstream.
Feel free to try it and reach to me for any doubts or feedback.
Okay, after a lot of time, I thought I should share the solution I found and that I'm currently using: devilbox. It's awesome, and once you get your head around it, it's incredibly powerful, flexible and customisable.
Related
I've successfully deployed the Laravel application to Heroku.
It works online.
But when I try to run "heroku local" I get:
vendor/bin/heroku-php-apache2: No such file or directory
Which makes sense, since looking into "vendor/bin", the only thing listed is:
psysh -> ../psy/psysh/bin/psysh
So, where's my heroku-php-apache or how do I fix this?
You should have these lines in your composer.json
"require-dev": {
"heroku/heroku-buildpack-php": "*"
}
be sure to run composer update after you add them.
After extensive research, trial and error and talking to the Heroku Support team, I found out that, although Slow Loris's answer was a part of the process, the following answer was given to me by Heroku's Support:
To cut a long story short, heroku local is not officially supported for PHP >applications. The reason is that unlike all the other languages we support on the >platform, PHP has no web servers written in userland. Instead, we use PHP-FPM >together with Apache or Nginx, and the boot scripts (vendor/bin/heroku-(php|hhvm)-(apache2|nginx)) dynamically inject the correct configuration for port >binding and the FastCGI comms sockets.
This works with vanilla PHP and Apache builds, provided that:
1) the current user has all the correct permissions (in your case, >/var/log/apache2/ isn't writable);
2) the correct proxy modules are loaded in the main httpd.conf;
3) the main httpd.conf doesn't bind to a port at all, or at least not to one >under 1024 (which are reserved for superusers).
The main config also needs to be handled by each user on their own, because >sometimes, the modules to be loaded are in libexec/, sometimes in >lib/apache2/modules/, and so forth. Just too many variations; otherwise, we could >ship a full Apache config to users and the experience would be much better.
But the problems don't end there. FPM does not work at all on Windows, and on >most Linux systems, httpd is not a command that works; instead, apache2ctl >handles starting and stopping, and thus, running a server in the foreground is >not possible. In the end, there are simply too many possible permutations in >system configs that make it impossible to ensure every user has a great >experience.
It's simply the current reality in PHP land. Ruby, Python, Node, Java all have >web servers that are written in each respective language, and you don't need >external servers. Which also makes it possible to stream file uploads, handle web >socket upgrades, and so forth. Maybe with PHP 7 we'll see something like that >emerge soon (in PHP 5 it's simply not feasible at all, because a fatal error >kills the engine, so your web server would be gone too).
I know this question is a little dated but I recently deployed a heroku app for the first time and was unable to get heroku local to work for me. I'm on the current branch of Laravel which is 5.8, I am also on Windows 10 using VS Code. I searched all over trying to rectify this issue and could not get it to work no matter what.
I did come up with a solution to be able to work on this locally with only a few lines in terminal.
In VS Code, I used gitbash terminal, once in my heroku project folder composer require laravel/homestead --dev, once that is complete, then we need to install homestead, vendor/bin/homestead make, and then once that is complete, simply run vagrant up and your app will be accessible through localhost:8000.
Docs - https://laravel.com/docs/5.8/homestead
Hope this helps someone!
What I have so far:
Two VirtualBox LAMP machines (separate locations) where I connect my two Windows development machines via SFTP, to write code using PHPStorm.
One VPS machine where I deploy my code written for a project in Laravel.
What I am trying to achieve:
Fast and easy code deployment, as in: write the code in Windows via PHPStorm, test it on the LAMP machine, deploy to VPS if necessary.
The problem is that I need to use some php artisan commands on LAMP machines to get some code generated. This means that I always have to synchronize PHPStorm with LAMP files tree in order to see the changes. Then, I need to also sync the other dev (LAMP) machine and the other PHPStorm running on Windows machine number 2. I know that this can be done via Git.
So everytime I use the command line to generate code, I need to sync 4 machines (excluding the deployment server).
Later, if I add another pair of Windows/LAMP dev machines, the complexity grows.
Back in the days of Dreamweaver, I could write code directly on the deployment server. Not the greatest idea, but it was way much simpler and faster, and that's what I need now.
Any ideas on how can I simplify this?
Switching to WAMP so I can have files in sync with PHPStorm (because all is locally) is not OK because... Windows and PHP libraries issues :)
Also, switching to Dreamweaver is not OK either.
What other options do I have?
Thanks!
LE: on the side, I am also thinking if a NAS can be helpful for this type of problem.
LLE: is Linux Desktop + PHPStorm the only straight solution?
No matter the protocols
You can put your code outside of the guest machine and configure the guest machine to mount the code (mount a folder from the host inside the guest).
Apache will run slower because it will use the mounted remote-folder but PHPStorm will run at its maximum speed.
Taking protocols into consideration
Try using SSHFS on windows.
I use SSHFS for remote development from my Linux host machine to headless vagrant boxes (and/or to remote development servers / staging servers).
It's much faster than SAMBA (the windows SMB protocol) and oddly faster than NFS even though SSH uses encryption.
Coleages using Windows+SMB often leave their computers for 30 min while PHPStorm is indexing and git branch changes on the dev machine go unnoticed for minutes at a time.
Indexing over SSHFS usually takes less than 5 min on a Symfony2 project. Branch changes are detected in less than 15s.
Using Linux (shameless plug)
Linux is nice, and it's free, and it works out of the box (Ubuntu) -- including pesky USB-Modems which would normally require an install on windows.
You already know how to handle a Linux CLI the learning curve is already halfway crossed.
Auto-updates don't rule your life, they're not the king of you!
All the applications you need are part of the software repositories you don't need to look for anything, download 40+ executables and attempt to install them just to be welcomed by an error "invalid architecture", "windows version not supported", ".NET framework version too old", "DirectX version too new (wtf?)", "your cousin is a software pirate".
Dependency management is a concept Linux never fully solved -- but at least the bloody tried and in 90% of consumer use-cases it fits the bill. Windows is still eating glue at the back of the class.
How I solved the problem:
I have an extra Mac, on which I installed everything for my PHP ecosystem, including the IDE, so everything is local. That's the dev machine. Then I manually copy the code to the VPS when needed. Another solution was to install Ubuntu Desktop (or similar) on dual boot with Windows and use it as a local dev environment.
Much faster development / deployment :)
I understand LAMP, MAMP and XAMP are solution stack. I also understand there are frameworks like Laravel and Symfony.
If I have to start PHP development in a proper manner, Is it required to have a solution stack installed first and then the framework to have a professional set up?
If the answer is yes, then I am assuming the versions of the software inside the package is quite important for compatibility with the framework. Is there a popular combination out there?
And In Live, I suppose, I just to need to have the solution stack installed for the package to run.
My dev machine is a MAC with OSX 10.9.5 and my Live is going to be in Linux. I need to make sure these fundamental knowledge is concrete before I start the work. Any help is much appreciated.
Laravel has a all-in one virtual box solution. It's called as Homestead. Homestead works on many platforms such as Linux, MAC, Windows and contains everything you needed:
Ubuntu 14.04
PHP 5.6
HHVM
Nginx
MySQL
Postgres
Node (With Bower, Grunt, and Gulp)
Redis
Memcached
Beanstalkd
Laravel Envoy
Blackfire Profiler
If you decide to go with other solutions you will probably face with many problems like enabling essential extensions and with changing some system settings.
Besides you can use this solution for pretty much every kind of php framework or code.
Just follow the steps in the guide and almost everything will be ready to use just in few minutes after download finishes.
Laravel is good choice as there is big community and Google trends show it is growing very fast.
As it is PHP then you need to have server which processes the PHP. Usually it is Apache2.
Many people like to use MAMP, XAMP to simplify their development. I prefer to use standard Apache2 myself and you can even just rely on Laravel/PHP builtin server that you can start with php artisan serve, It will be enough for defelopment purposes.
Hello i was wondering if anyone had to install/or is working with Zend Server.
My Question is: If i install Zend Server on a production server will it mess up my existing PHP configuration? Will i have to bring my application offline first or will Zend Server install without problems?
The application must run 24/7 and i need a reliable PHP Stack that will boost performance. Any comments on the performance part of Zend Server? Does it worth the installation?
Thanks,
That's no way to think about handling a production server.
I'm not experienced with the Zend Server product, but I wouldn't just install anything on top of a running production system.
Instead, get yourself a new server that will eventually replace your production server.
Then:
Start with a clean install of your distro of choice.
Install ZS (take notes on exactly what you do)
Install your application and data (take notes on exactly what you do)
Test it thoroughly.
If it works, nuke the server, and repeat 1-4, using your notes.
Once you're satisfied that you can get everything working "from scratch" using your notes, create a plan to migrate from the old server to the new one.
Doing it this way ensures that
You have minimal downtime.
You don't have some mess with ZS installed over the top of some other set up.
You can re-build your server when necessary (you created documentation)
2016 Edit: These days, there are various tools such as chef, ansible, or salt that replace obsessive note-taking with automation. I highly recommend anyone managing production systems learn one or more and use them liberally.
When Zend Server is installed on Linux boxes, it will replace the PHP packages supplied by the distribution, and some other packages which supply some PHP functionality. As tim said, it is better for you not to replace the production server environment on the first round, as not always things will work as expected, even to the advanced users.
Take another machine with similar environment and make it your staging/development environment. This will allow you to play with Zend Server features without actually taking down your production server and sites. At the moment you are sure everything works as expected, and only than, start thinking about changing your production site.
To run multiple LAMP servers on Ubuntu, I use XAMPP for Linux and Bitnami LAMP Stack .
By default, the first works on port 80, the second on 8080. Hence they don't conflict. If you know a little about Apache configuration, and if can write a few simple scripts, you can do many things.
However, doing anything on a production server is dangerous.
Both XAMPP and Bitnami stacks are meant to be development environments.
See timdev's answer, +1 to that.
We have various php projects developed on windows (xampp) that need to be deployed to a mix of linux/windows servers.
We've used capistrano in the past to deploy from windows to the linux servers, but recent changes in architecture and windows servers left the old config not working. The recipe works fine for the linux deployment, but setting up the windows servers has required more time than we have right now. Ideas for the Capistrano recipe are valid answers. obviously the windows/linux servers don't share users, so this complicates it a tad (for the capistrano assumption of same username/password everywhere).
Currently we're using svn-update for the windows servers, which i dislike, since it leaves all the svn files hanging on the production servers. (and we still have to manually svn-update them on windows) And manual updating of files using winscp and syncing the directories with their linux counterparts.
My question is, what tools/setup do you suggest to automatize this deployment scenario:
"Various php windows/linux developers deploying to 2+ mixed windows/linux machines"
(ps: we have no problems using linux tools or anything working through cygwin, we simply need to make deployment a simple one-step operation)
edit: Currently we can't work on a all-linux enviroment, we have to deploy to both linux and windows server. We can start the deploy from anywhere, but we'd prefer to be able to do it from either enviroment.
I use 4 different approaches depending on the client environment:
Capistrano and similar tools (effective, but complex)
rsync from + to Windows, Linux, Mac (simple, doesn't enforce discipline)
svn from + to Windows, Linux, Mac (simple, doesn't enforce discipline)
On-server scripts (run through the browser, complex)
There are some requirements that drive what you need:
How much discipline you want to enforce
If you need database (or configuration) migrations (up and/or down)
If you want a static "we're down" page
Who can do the update
Configuration differences between servers
I strongly suggest enforcing enough discipline to save you from yourself: deploy to a development server, allow for upward migrations and simple database restore, and limit who can update the live server to a small number of responsible admins (where the dev server is open to more developers). Also consider pushing via a cron job (to the development server), so there's a daily snapshot of your incremental changes.
Most of the time, I find that either svn or rsync setups are enough, with a few server-side scripts, especially when the admin set is limited to a few developers.
This will probably sound silly but... I used to have this kind of problem all the time until I decided in the end that if I'm always deploying on Linux, I ought really to at least try developing on Linux also. I did. It was pain free. I never went back.
Now. I am not suggesting this is for everyone. But, if you install VirtualBox you could run a Linux install as a local server on your windows box. Share a folder in the virtual machine and you can use all your known and trusted Windows software and techniques and have the piece of mind of knowing that everything is working well on its target platform.
Plus you'll be able to go back to Capistrano (a fine choice) for deployment.
Best of all, if you thought you knew Linux / Unix wait until you use it everyday on your desktop! Who knows you may even like it :)
Capistrano is the nicest deployment tool I've seen. Do the architecture changes make it impossible to fix the configs so it works again?
Why you can't use capistrano anymore?
Why you dislike svn-update?
What things in your app requires an special deployment ?
You can setup svn:ignore property on configuration files, so that svn update doesn't erase them, and then use svn export /target/path/ to get rid of .svn files in your Subversion repository.