I work with Docker for all my projects, however I have a problem with Symfony 3.4 and Composer with Docker .
When I add some more packages, Composer freezes on update and I need to restart Docker to unblock the situation.
I have no idea whether the problem comes from Symfony or Composer.
I think it's comes from Symfony because when I try with Symfony 4.3 there are no problems.
Can you help me to find a clue to resolve this problem?
Generally, I launch Composer with the following command line:
docker run --rm --name composer -ti -w /var/www -v %cd%:/var/www composer ...
I have resolve my problem,
set 4G RAM for Docker and it work.
Related
I have been using Laravel Vapor for several years now using native runtimes and have never had an issue until recently when needing to use the Imageick PHP extension. Native runtimes don't support PHP extensions so I decided to try using a docker runtime on a staging server and everything went smoothly until I tried to run the migrate command in the Vapor UI. Getting the following error in Vapor-UI:
sh: /opt/bin/php: not found
Have tried unsuccessfully searching for the location of php in the staging deployment as well as adding alias for php in my dockerfile. Here is my current staging.Dockerfile:
ARG VERSION=php81
FROM laravelphp/vapor:${VERSION}
RUN apk add imagemagick imagemagick-dev php81-pecl-imagick \
&& pecl install imagick \
&& docker-php-ext-enable imagick
COPY . /var/task
Has anyone run in to this issue before? Seems too simple but I have zero experience with Docker and after reading through some documentation I could understand why it wouldn't be available, but then during deployment on vapor I would have thought there would be issues... and if its not available is there any way to access php in the Vapor UI by adding something to the Dockerfile or elsewhere?
https://laravel.com/docs/9.x/sail
I did a clean Laravel install with Sail on computer 1. It is all setup and working with all containers running (mysql, laravel, redis, etc) and Docker Desktop is showing that it is connected to Windows WSL2 and running in that environment. I never had to install PHP as this install procedure took care of the entire environment.
However, I would now like to pull this repo down on Computer 2 and run it in containers as well. So I pulled down the repo, it didn't have a devcontainers folder, only docker-compose.
I tried running docker compose up and the error is the vendor folder is empty/non existent for obvious reasons.
Now, I could install PHP with the right version and then install composer install and then try again. But that doesn't seem right to me.
Shouldn't I be able to just run this repo as a remote container in Vscode and have it running everything on its own?
How do I get the vendor/bin/sail folders installed?
I went back to computer 1 and created a devcontainer folder using remote-containers, pulled that down onto computer 2 but computer is still does not have the right vendor folder and files to complete the operations.
What am I doing wrong?
Assuming you have Docker working correctly at the second computer, you could run a temporary sail container just to install the composer dependencies in said project, as explained in the Laravel Sail documentation
docker run --rm \
-u "$(id -u):$(id -g)" \
-v $(pwd):/var/www/html \
-w /var/www/html \
laravelsail/php81-composer:latest \
composer install --ignore-platform-reqs
https://laravel.com/docs/9.x/sail#installing-composer-dependencies-for-existing-projects
After this the temporary container will not exist anymore and you can now run ./vendor/bin/sail up -d normally.
Hi i tried to install fresh Laravel project using
Laravel Sail
docker environment. First it was showing me "Docker is not running" error. Then i found out, i needed to start docker as rootless. I solved it, reading this url: [https://docs.docker.com/engine/install/linux-postinstall/].
After that, I successfully installed Laravel using Laravel Sail. Then I ran
./vendor/bin/sail up -d
I was able to view Laravel project in my browser. But when i ran any other artisan commands such as ./vendor/bin/sail artisan route:list or sail commands as sail shell, all the docker containers were forced closed automatically. It shows me this error.
Sail is not running.
You may Sail using the following commands: './sail up' or './sail up
-d'
Any suggestions? I am getting this issue on Ubuntu 20.04 LTS version.
If you are on Windows and using WSL, make sure the WSL Integration is properly set:
Settings->Ressources->WSL Integration + Toggle Linux version
I was using Laradock before installing Laravel Sail. Maybe there were some conflicts. So I backed up all my databases, then I removed all containers using this code. sudo docker rmi -f $(docker images -a -q). Then installed fresh Laravel project and it worked.
Please read my below comment as it is was a better solution for me.
very easy, maybe you don't have permission to run docker.
in Linux first use sudo -s and after user ./vendor/bin/sail up -d
Sail first checks to see if any current docker-compose processes have a status of Exit. If any of them have, then it will forcefully bring down all other services. Which is what you were are seeing whenever you type any sail sub-command. You can see the code here: https://github.com/laravel/sail/blob/87c63c2956749f66e43467d4a730b917ef7428b7/bin/sail#L44-L49
Run sail up to start the processes and then use docker-compose ps to check all services are running and none have an Exit status.
I had the same issue and when reviewing the code and checking my services I noticed the database had exited soon after I brought them up.
I need to run composer on my ddev project and don't have it on my Windows machine. For example, the project requires a composer install before startup. How can I use composer in this environment, especially on Windows?
Updated 2018-11-15 to show native ddev support (ddev composer command)
There are several ways to run composer for your project.
ddev v1.4.0 now has the ddev composer and ddev composer create commands. These run composer inside the container, so you're guaranteed to get composer behavior that matches the in-container hosting environment. (This matters most for Windows users.)
ddev composer require swiftmailer/swiftmailer
ddev composer update
ddev composer install
ddev composer create drupal-composer/drupal-project:8.x-dev --stability dev
Note that ddev composer create is not exactly the same as composer create-project so you don't have to understand complexities of the underlying filesystem. There are drupal and TYPO3 ddev composer create examples in the docs.
Nothing here prevents you from using any composer technique that you're comfortable with, but this is a great way to get predictable on-linux in-container composer builds. It should be hugely important for people using Windows OS, where composer is less available and has some unpredictable behavior.
Install on the host the old fashioned way: If composer is installed on your computer/host, just composer install. However, that only works on macOS and Linux, and only works if you have the right versions of php related components. It does not work well at all on Windows (NTFS) because the symlinks composer creates are not compatible with usage inside the (Linux) web container. (Composer is not hard to install on Windows: Use chocolatey and choco install -y composer. You'll want to enable the gd and curl extensions in c:\tools\php72\php.ini)
All the normal composer behavior has always been installed inside your web container, so you can use that whether or not you have composer on your host computer. For example: ddev exec composer install -d /var/www/html will do a composer install in the root of your repository, exactly the same as ddev composer install. You can also do ddev ssh and operate on the command line in the container.
Try this hooks approach to running composer install inside the container (on the mounted partition) every time your project starts:
hooks:
post-start:
- exec: composer install -d /var/www/html
For some older ideas on composer patterns (mostly obsoleted by ddev composer, See
How to: Use "composer create-project" and DDEV to start a new Drupal 8 site when Composer isn't installed on the host machine and
How to: Set up a D8/Composer site on Pantheon without CircleCI, custom upstreams
To expand on the accepted answer, DDEV now has a composer-specific hook.
hooks:
post-start:
- composer: install -d /var/www/html
The reason for using this instead of exec, I assume, is that there are also pre-composer and post-composer hooks, so maybe this also executes those hooks. I'm not sure of that or the actual difference, though.
If I run composer install from my host, I hit my local composer cache:
- Installing deft/iso3166-utility (1.0.0)
Loading from cache
Yet when building a container having in its Dockerfile:
RUN composer install -n -o --no-dev
I download all the things, e.g.:
- Installing deft/iso3166-utility (1.0.0)
Downloading: 100%
It's expected, yet I like to avoid it. As even on a rebuilt, it would also download everything again.
I would like to have a universal cache for composer that I could also reshare for other docker projects.
I looked into this and found the approach to define a volume in the Dockerfile:
ENV COMPOSER_HOME=/var/composer
VOLUME /var/composer
I added that to my Dockerfile, and expected to only download the files once, and hit the cache afterwards.
Yet when I modify my composer, e.g. remove the -o flag, and rerun docker build ., I expected to hit the cache on build, yet I still download the vendors again.
How are volumes supposed to work to have a data cache inside a docker container?
Use the experimental feature : Docker buildkit (Supported Since docker 18.09, docker-compose 1.25.4)
In your dockerfile
# syntax=docker/dockerfile:experimental
FROM ....
# ......
RUN --mount=type=cache,target=/var/composer composer install -n -o --no-dev
Now before building, make sure the env var is exported:
export DOCKER_BUILDKIT=1
docker build ....
If you are using docker-compose, make sure to export also COMPOSE_DOCKER_CLI_BUILD :
export COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1
docker-compose build ...
If it does not work with docker-compose, make sure your docker-compose version is above 1.25.4
docker-compose version
I found two ways of dealing with this problem, yet none deal with composer volumes anymore.
Fasten composer download process: Use hirak/prestissimo
composer global require "hirak/prestissimo:^0.3"
💡 With Composer 2.0, the above step is no longer required for faster downloads. In fact, it won't install on Composer 2.0 environments.
Force docker to use a cached composer install. Docker uses a cache on a RUN if the added files didn't change. If you only do COPY . /your-php-app, docker build will refresh all the cashes and re-run composer install even if only one unrelated file in the source tree changed. In order to make docker build to run composer install only install on package changes, one has to add composer.json and composer.lock file before adding the source files. Since one also needs the source files anyway, one has to use different folders for composer install and rsync the content back to the then added folder; furthermore one then has to run the post-install scripts manually. It should look something like this (untested):
WORKDIR /tmp/
COPY composer.json composer.lock ./
RUN composer install -n -o --no-dev --no-scripts
WORKDIR /your-php-app/
COPY . /your-php-app/
RUN rsync -ah /tmp/* /your/php-app/
RUN composer run-script post-install-cmd
or combine the two =)
I would like to have a universal cache for composer that I could also reshare for other docker projects.
Using a shared volume for the Composer cache works great when working with containers. If you want to go broader than just containers, and use a shared cache for e.g. local development as well, I've developed a solution for that called Velocita - how it works.
Basically, you use one global Composer plugin for local projects and inside and build containers. This not only speeds up downloads tremendously, it also helps with 3rd party outage for example.
I would consider utilizing the $HOME/.composer/cache/files directory. This is where composer reads/write to when using composer install.
If you are able to mount it from your host to your container that would work. Also you could just tar it up after each time your run composer install and then drop that in before you run composer install the next time.
This is loosely how Travis CI recommends doing this.
Also, consider using the --prefer-dist flag with your composer install command.
Info on that can be found here: https://getcomposer.org/doc/03-cli.md#install
--prefer-dist: Reverse of --prefer-source, composer will install from dist if possible. This can speed up installs substantially on build servers and other use cases where you typically do not run updates of the vendors. It is also a way to circumvent problems with git if you do not have a proper setup.
Some references on utilizing the composer cache for you:
https://blog.wyrihaximus.net/2015/07/composer-cache-on-travis/
https://github.com/travis-ci/travis-ci/issues/4579