How To Create Symfony Applications with Multiple Kernels ¶

Adding a new Kernel to the Application ¶

Creating a new kernel in a Symfony application is a three-step process:

1. Create a new front controller to load the new kernel;
   新しいカーネルをロードする新しいフロント コントローラーを作成します。
2. Create the new kernel class;
   新しいカーネル クラスを作成します。
3. Define the configuration loaded by the new kernel.
   新しいカーネルによってロードされる構成を定義します。

The following example shows how to create a new kernel for the API of a given Symfony application.

1
2
3
4
5
6
7

// public/api.php
// ...
$kernel = new ApiKernel(
    $_SERVER['APP_ENV'] ?? 'dev',
    $_SERVER['APP_DEBUG'] ?? ('prod' !== ($_SERVER['APP_ENV'] ?? 'dev'))
);
// ...

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

// src/ApiKernel.php
use Symfony\Bundle\FrameworkBundle\Kernel\MicroKernelTrait;
use Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator;
use Symfony\Component\HttpKernel\Kernel as BaseKernel;
use Symfony\Component\Routing\Loader\Configurator\RoutingConfigurator;

class ApiKernel extends Kernel
{
    use MicroKernelTrait;

    public function getProjectDir(): string
    {
        return \dirname(__DIR__);
    }

    public function getCacheDir(): string
    {
        return $this->getProjectDir().'/var/cache/api/'.$this->environment;
    }

    public function getLogDir(): string
    {
        return $this->getProjectDir().'/var/log/api';
    }

    protected function configureContainer(ContainerConfigurator $container): void
    {
        $container->import('../config/api/{packages}/*.yaml');
        $container->import('../config/api/{packages}/'.$this->environment.'/*.yaml');

        if (is_file(\dirname(__DIR__).'/config/api/services.yaml')) {
            $container->import('../config/api/services.yaml');
            $container->import('../config/api/{services}_'.$this->environment.'.yaml');
        } else {
            $container->import('../config/api/{services}.php');
        }
    }

    protected function configureRoutes(RoutingConfigurator $routes): void
    {
        $routes->import('../config/api/{routes}/'.$this->environment.'/*.yaml');
        $routes->import('../config/api/{routes}/*.yaml');
        // ... load only the config routes strictly needed for the API
    }

    // If you need to run some logic to decide which bundles to load,
    // you might prefer to use the registerBundles() method instead
    private function getBundlesPath(): string
    {
        // load only the bundles strictly needed for the API
        return $this->getProjectDir().'/config/api_bundles.php';
    }
}

Executing Commands with a Different Kernel ¶

The bin/console script used to run Symfony commands always uses the default Kernel class to build the application and load the commands. If you need to run console commands using the new kernel, duplicate the bin/console script and rename it (e.g. bin/api).

Then, replace the Kernel instance by your own kernel instance (e.g. ApiKernel). Now you can run commands using the new kernel (e.g. php bin/api cache:clear).

Rendering Templates Defined in a Different Kernel ¶

If you follow the Symfony Best Practices, the templates of the default kernel will be stored in templates/. Trying to render those templates in a different kernel will result in a There are no registered paths for namespace "__main__" error.

In order to solve this issue, add the following configuration to your kernel:

1
2
3
4
5

# config/api/twig.yaml
twig:
    paths:
        # allows to use api/templates/ dir in the ApiKernel
        "%kernel.project_dir%/api/templates": ~

Running Tests Using a Different Kernel ¶

In Symfony applications, functional tests extend by default from the WebTestCase class. Inside that class, a method called getKernelClass() tries to find the class of the kernel to use to run the application during tests. The logic of this method does not support multiple kernel applications, so your tests won't use the right kernel.

The solution is to create a custom base class for functional tests extending from WebTestCase class and overriding the getKernelClass() method to return the fully qualified class name of the kernel to use:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;

// tests needing the ApiKernel to work, now must extend this
// ApiTestCase class instead of the default WebTestCase class
class ApiTestCase extends WebTestCase
{
    protected static function getKernelClass()
    {
        return 'App\ApiKernel';
    }

    // this is needed because the KernelTestCase class keeps a reference to
    // the previously created kernel in its static $kernel property. Thus,
    // if your functional tests do not run in isolated processes, a later run
    // test for a different kernel will reuse the previously created instance,
    // which points to a different kernel
    protected function tearDown()
    {
        parent::tearDown();

        static::$class = null;
    }
}

Adding more Kernels to the Application ¶

If your application is very complex and you create several kernels, it's better to store them in their own directories instead of messing with lots of files in the default src/ directory:

1
2
3
4
5
6
7
8
9
10
11
12

project/
├─ src/
│  ├─ ...
│  └─ Kernel.php
├─ api/
│  ├─ ...
│  └─ ApiKernel.php
├─ ...
└─ public/
    ├─ ...
    ├─ api.php
    └─ index.php