Docker php cli log

Почему PHP CLI контейнер сам останавливается в docker?

Как должно быть правильно? Как мне спокойно работать с контейнером и выполнять операции внутри него (композер запускать, воркеры держать)?

version: "3" services: nginx: image: nginx:latest ports: - "8080:80" volumes: - .:/app - ./docker/nginx/site.conf:/etc/nginx/conf.d/default.conf depends_on: - php-fpm working_dir: /app php-fpm: working_dir: /app build: context: ./docker/php-fpm dockerfile: Dockerfile volumes: - .:/app - ./docker/php-fpm/log/php-error.log:/var/log/error.log ports: - '9000:9000' php-cli: working_dir: /app build: context: ./docker/php-cli dockerfile: Dockerfile volumes: - ./docker/php-cli/log/php-error.log:/var/log/error.log

memory_limit = 1024M error_reporting = E_ALL display_errors = On log_errors = On html_errors = Off error_log = /var/log/error.log

FROM php:7.3.6-cli RUN apt-get update \ && apt-get upgrade -y \ && apt-get install -y git \ && apt-get install -y libfreetype6-dev libjpeg62-turbo-dev libpng-dev libxslt-dev libpq-dev unzip\ && docker-php-ext-install -j$(nproc) iconv \ && docker-php-ext-install ctype \ && docker-php-ext-install mysqli pdo pdo_mysql \ && docker-php-ext-enable pdo_mysql \ && docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ \ && docker-php-ext-install -j$(nproc) gd \ && docker-php-ext-install xsl \ && pecl install xdebug-2.7.2 \ && docker-php-ext-enable xdebug COPY xdebug.ini /usr/local/etc/php/conf.d/xdebug.ini COPY php.ini /usr/local/etc/php/conf.d/php.ini RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/bin --filename=composer --quiet WORKDIR /app

Источник

How to configure PHP logs for Docker

If you are using docker and cloud services to run your application live, you should manage your logs.

The most common method to store them is to put them in the text file. It’s the default configuration for most backend frameworks. This option is ok if you run your application locally or on the VPS server for test.

When you run your application in a production environment, you should choose a better option to manage your logs. Almost every cloud has a tool for rotating logs or if not, you can use for example Grafana Loki or ELK stack. Those solutions are better because give you interfaces to rotate and search your logs. Also, you have easy access to them, you no need to connect to your server to review them.

If you are using Docker containers, and you running your application in cloud services, often they will be automatically writing the logs of your containers to tools like AWS CloudWatch or GCloud Stackdriver. But first, you need to redirect your log streams to the output of the Docker container to be able to use them.

Linux streams

Docker containers are running the Linux processes. In linux every running process has 3 streams, STDIN , STDOUT , STDERR . STDIN it’s command input stream, that you can provide for ex. by your keyboard. STDOUT is the stream where the running command may print the output. STDERR is the standard error stream, but the name I think is a bit confusing, because it is basically intended for diagnostic output. When you run the docker logs [container] command in your terminal, you will see the output of STDOUT and STDERR streams. So our goal is to redirect our logs to one of those streams. Official docker documentation page

PHP-FPM

In PHP we are often running our application using the PHP-FPM (Process Manager). If you run your docker with FPM inside a docker container, and you run the docker logs command, you should see the output with processed requests, or errors. So the PHP-FPM is already writing its output to STDOUT .

The PHP-FPM allow us to catch workers output and forward them to the STDOUT . To do that we need to make sure that the FPM is configured properly. You can create new config file, and push it for example to the /usr/local/etc/php-fpm.d/logging.conf file:

[global] error_log = /proc/self/fd/2 [www] access.log = /proc/self/fd/2 catch_workers_output = yes decorate_workers_output = no 

The error_log and access.log parameters are configuration of streams of logs output.

The catch_workers_output option is turning on the worker’s output caching. The decorate_workers_output is the option that turns off the output decoration. If you leave this option turned on, FPM will decorate your application output like this:

[21-Mar-2016 14:10:02] WARNING: [pool www] child 12 said into stdout: "[your log line]" 

Remember that decorate_workers_output option is available only for PHP 7.3.0 and higher. If you are using official docker php-fpm image, this configuration is already set in the /usr/local/etc/php-fpm.d/docker.conf file, so you no need to do anything more 😎

PHP application configuration

Right now everything that will be put to the stdout from PHP workers will be shown in our docker logs. But when logs are forwarded to that stream in PHP? To write something to STDIN on PHP level, we need to just write to the php://stdout stream. In the simplest way you can do this like that:

 file_put_contents('php://stdout', 'Hello world'); 

When you execute this code in php cli, you will get the Hello world text on the output. But it’s not the optimal way to push your logs to the STDOUT . Every modern framework should have a PSR-3 Logger. I think that the most popular now is the monolog, so I will show you how to configure it in Symfony, Laravel, and in pure usage.

Monolog

Basic monolog configuration

If you are using monolog in your project with manual configuration, you need to configure handler in this way: (Modified documentation example)

 use Monolog\Logger; use Monolog\Handler\StreamHandler; $log = new Logger('stdout'); $log->pushHandler(new StreamHandler('php://stdout', Logger::DEBUG)); $log->debug('Foo'); 

Symfony

Symfony Kernel since the Flex was provided, is using minimalist PSR-3 logger, that logs everything to php://stderr by default. In Symfony, monolog as other components is configured in YAML files. So the same configuration will look like this:

# config/packages/monolog.yaml monolog: handlers: stdout: type: stream path: "php://stdout" level: debug 

Laravel

# config/logging.php  use Monolog\Handler\StreamHandler; return [ 'channels' => 'stdout' => [ 'driver' => 'monolog', 'handler' => StreamHandler::class, 'level' => env('LOG_LEVEL', 'debug'), 'with' => [ 'stream' => 'php://stdout', ], ], ]; 

STDERR or STDOUT

In some articles on the internet, you can read that someone uses stderr, and someone uses stdout streams to write logs there. Right now I cannot fin any reasons to choose one of them which is better.

The only information that I found on this topic is that post.

Источник

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Where is the error.log? #212

Where is the error.log? #212

Comments

I need some advice from more seasoned docker users.

I am extending the official php-image in my Dockerfile like this:

 FROM php:5.6-apache MAINTAINER "John Doe " COPY ./templates/apache2files/piwik /var/www/html/ COPY ./templates/php.ini /usr/local/etc/php/ RUN chmod 777 -R /var/www/html/ RUN docker-php-ext-install mysqli RUN docker-php-ext-install mbstring 

I build the dockerfile with this:

I run the container like this:

docker run -d --name mypiwikcontainer -p "8888:80" mypiwik:latest 

I can see the access.log using this:

docker logs mypiwikcontainer 

How can I see the error.log.

The text was updated successfully, but these errors were encountered:

@keltik85
I had the same issue and solved it the following way:

In your php.ini , add the following lines:

log_errors = On error_log = /dev/stderr 

Now you’ll be able to see any PHP error logs as part of the docker container log stream:

docker logs -f your_php_apache_container

To display only errors and hide the access log, you can pipe stdout to /dev/null :

docker logs -f your_php_apache_container >/dev/null

To follow only the access log, you can pipe stderr to /dev/null :

docker logs -f your_php_apache_container 2>/dev/null

It’s cool, but how to get actual log files?

check that 000-default site is enabled for your apache,
in my case /etc/apache2/sites-enabled/ does not contained softlink to 000-default.conf

a2ensite 000-default apache2ctl restart 

then i started seeing logs in access.log and error.log

@povils Container apps shouldn’t write log files in the container, as its lifecycle is meant to be «disposable», unless you mount a volume and want them on your file system. This is a core tenet of the 12-factor-app methodology.

If you docker exec -it app-name ls -alh /var/log/apache2/ you will see the log files are symlinked to /dev/stderr and /dev/stdout as they should. This allows the container engine to expose logs via the docker logs -f app-name command or an orchestrator like Swarm or Kubernetes to expose them to centralized logging like ELK stack or Stackdriver.

@mikesparr Thanks for the answer. I needed log files because I am using Elastic Filebeat which harvests log files and streams that to our ELK

I believe you enable fluentd and configure logging output. The ephemeral nature of containers is meant to stream logs not write them so you need to capture the stream one layer up, then ship em.

On Oct 20, 2017, at 2:51 AM, Povilas Susinskas ***@***.***> wrote: @mikesparr Thanks for the answer. I needed log files because I am using Elastic Filebeat which harvests log files and streams that to our ELK — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Источник