구성

모든 프레임워크는 구성 파일을 사용하여 수많은 매개변수와 초기 설정을 정의합니다. CodeIgniter 구성 파일은 필수 설정이 공용 속성인 간단한 클래스를 정의합니다.

다른 많은 프레임워크와 달리 CodeIgniter 구성 가능 항목은 단일 파일에 포함되지 않습니다. 대신 구성 가능한 항목이 필요한 각 클래스에는 해당 항목을 사용하는 클래스와 동일한 이름의 구성 파일이 있습니다. app/Config 폴더에서 애플리케이션 구성 파일을 찾을 수 있습니다.

구성 클래스란 무엇입니까?

구성 클래스는 시스템 기본 구성 값을 정의하는 데 사용됩니다. 시스템 구성 값은 일반적으로 static입니다. 구성 클래스는 각 사용자의 개별 설정에 응답하는 대신 애플리케이션 작동 방식을 구성하는 설정을 유지하기 위한 것입니다.

나중에 실행하는 동안 구성 클래스를 인스턴스화하는 동안 설정된 값을 변경하는 것은 권장되지 않습니다. 즉, 구성 클래스를 불변 클래스 또는 읽기 전용 클래스로 처리하는 것이 좋습니다. Config Caching을 활용하는 경우 이는 특히 중요합니다.

구성 값은 클래스 파일에 하드 코딩되거나 인스턴스화 시 환경 변수에서 얻을 수 있습니다.

구성 파일 작업

구성 개체 가져오기

여러 가지 방법으로 클래스의 구성 파일에 액세스할 수 있습니다.

새 키워드

new 키워드를 사용하여 인스턴스를 생성합니다.

<?php

// Creating new configuration object by hand
$config = new \Config\Pager();

config()

config() 함수를 사용하여:

<?php

// Get shared instance with config function
$config = config('Pager');

// Access config class with namespace
$config = config('Config\\Pager');
$config = config(\Config\Pager::class);

// Creating a new object with config function
$config = config('Pager', false);

네임스페이스가 제공되지 않으면 먼저 app/Config 폴더에서 파일을 찾고, 찾지 못한 경우 정의된 모든 네임스페이스의 Config 폴더에서 찾습니다.

CodeIgniter와 함께 제공되는 모든 구성 파일은 Config으로 네임스페이스가 지정됩니다. 애플리케이션에서 이 네임스페이스를 사용하면 파일을 찾을 위치를 정확히 알 수 있으므로 최상의 성능을 제공할 수 있습니다.

참고

v4.4.0 이전에는 config(\Acme\Blog\Config\Blog::class)와 같은 정규화된 클래스 이름을 지정하더라도 동일한 단축 이름을 가진 클래스가 있는 경우 config()이 app/Config/에서 파일을 찾습니다. 이 동작은 v4.4.0에서 수정되었으며 지정된 인스턴스를 반환합니다.

구성 속성 가져오기

모든 구성 개체 속성은 공개되므로 다른 속성과 마찬가지로 설정에 액세스할 수 있습니다.

<?php

$config = config('Pager');
// Access settings as object properties
$pageSize = $config->perPage;

구성 파일 생성

새 구성이 필요한 경우 먼저 원하는 위치에 새 파일을 만듭니다. 기본 파일 위치(대부분의 경우 권장됨)는 app/Config입니다.

다른 네임스페이스를 사용하여 모든 Config 폴더에 구성 파일을 넣을 수 있습니다.

클래스는 적절한 네임스페이스를 사용해야 하며 환경별 설정을 수신할 수 있도록 CodeIgniter\Config\BaseConfig을 확장해야 합니다.

클래스를 정의하고 설정을 나타내는 공용 속성으로 채웁니다.

<?php

namespace Config;

use CodeIgniter\Config\BaseConfig;

class CustomClass extends BaseConfig
{
    public $siteName  = 'My Great Site';
    public $siteEmail = 'webmaster@example.com';
    // ...
}

환경 변수

오늘날 애플리케이션 설정에 대한 모범 사례 중 하나는 환경 변수를 사용하는 것입니다. 그 이유 중 하나는 코드를 변경하지 않고도 배포 간에 환경 변수를 쉽게 변경할 수 있기 때문입니다. 구성은 배포 전반에 걸쳐 많이 변경될 수 있지만 코드는 그렇지 않습니다. 예를 들어 개발자의 로컬 시스템 및 프로덕션 서버와 같은 여러 환경에는 일반적으로 각 특정 설정에 대해 서로 다른 구성 값이 필요합니다.

환경 변수는 비밀번호, API 키 또는 기타 민감한 데이터와 같은 개인 정보에도 사용해야 합니다.

Dotenv 파일

CodeIgniter를 사용하면 “dotenv” 파일을 사용하여 환경 변수를 간단하고 쉽게 설정할 수 있습니다. 이 용어는 “env”라는 텍스트 앞에 점으로 시작하는 파일 이름에서 유래되었습니다.

Dotenv 파일 생성

CodeIgniter는 .env 파일이 app 디렉터리와 함께 프로젝트 루트에 있을 것으로 예상합니다. env라는 프로젝트 루트에 있는 CodeIgniter와 함께 배포되는 템플릿 파일이 있습니다. (시작 부분에 점(.)이 없습니다.)

여기에는 빈 값, 더미 값 또는 기본값이 할당되어 프로젝트에서 사용할 수 있는 대규모 변수 컬렉션이 있습니다. 템플릿 이름을 .env으로 바꾸거나 .env이라는 이름의 복사본을 만들어 이 파일을 애플리케이션의 시작 위치로 사용할 수 있습니다.

경고

버전 제어 시스템에서 .env 파일을 추적하지 않는지 확인하세요. git의 경우 이는 .gitignore에 추가하는 것을 의미합니다. 그렇지 않으면 민감한 자격 증명이 대중에게 노출될 수 있습니다.

변수 설정

설정은 등호로 구분된 이름/값 쌍의 간단한 컬렉션으로 .env 파일에 저장됩니다.

S3_BUCKET = dotenv
SECRET_KEY = super_secret_key
CI_ENVIRONMENT = development

애플리케이션이 실행되면 .env이 자동으로 로드되고 변수가 환경에 배치됩니다. 변수가 환경에 이미 존재하는 경우 덮어쓰이지 않습니다.

변수 얻기

로드된 환경 변수는 getenv(), $_SERVER 또는 $_ENV 중 하나를 사용하여 액세스됩니다.

<?php

$s3_bucket = getenv('S3_BUCKET');
$s3_bucket = $_ENV['S3_BUCKET'];
$s3_bucket = $_SERVER['S3_BUCKET'];

경고

.env 파일의 설정이 $_SERVER 및 $_ENV에 추가됩니다. 부작용으로 이는 CodeIgniter 애플리케이션이 (예를 들어) var_dump($_ENV) 또는 phpinfo()``(디버깅 또는 기타 유효한 이유로)를 생성하거나 ``development 환경의 자세한 오류 보고서가 표시되는 경우 your secure credentials are publicly exposed을 의미합니다.

중첩 변수

입력 시간을 절약하려면 ${...} 내에 변수 이름을 래핑하여 파일에 이미 지정한 변수를 재사용할 수 있습니다.

BASE_DIR = "/var/webroot/project-root"
CACHE_DIR = "${BASE_DIR}/cache"
TMP_DIR = "${BASE_DIR}/tmp"

네임스페이스 변수

동일한 이름을 가진 여러 변수가 있을 때가 있습니다. 시스템에는 올바른 설정이 무엇인지 알 수 있는 방법이 필요합니다. 이 문제는 변수를 “namespacing”하여 해결됩니다.

네임스페이스 변수는 점 표기법을 사용하여 변수 이름을 한정하므로 환경에 통합될 때 고유하게 됩니다. 이는 식별 접두사, 점(.), 변수 이름 자체를 포함하여 수행됩니다.

// not namespaced variables
name = "George"
db = my_db

// namespaced variables
address.city = "Berlin"
address.country = "Germany"
frontend.db = sales
backend.db = admin
BackEnd.db = admin

네임스페이스 구분자

Docker, CloudFormation과 같은 일부 환경에서는 점(.)이 포함된 변수 이름을 허용하지 않습니다. 이 경우 v4.1.5부터 밑줄(_)을 구분 기호로 사용할 수도 있습니다.

// namespaced variables with underscore
app_forceGlobalSecureRequests = true
app_CSPEnabled = true

구성 클래스 및 환경 변수

구성 클래스를 인스턴스화할 때 구성 개체의 속성에 병합하기 위해 모든 namespaced 환경 변수가 고려됩니다.

중요

환경 변수를 설정하여 새 속성을 추가하거나 스칼라 값을 배열로 변경할 수 없습니다. 데이터를 대체하는 환경 변수을 참조하세요.

참고

이 기능은 CodeIgniter\Config\BaseConfig 클래스에서 구현됩니다. 따라서 클래스를 확장하지 않는 app/Config 폴더의 일부 파일에서는 작동하지 않습니다.

네임스페이스 변수의 접두사가 구성 클래스의 네임스페이스와 정확히 일치하는 경우 설정의 후행 부분(점 뒤)이 구성 속성으로 처리됩니다. 기존 구성 속성과 일치하는 경우 환경 변수 값이 구성 파일의 해당 값을 대체합니다. 일치하는 항목이 없으면 구성 클래스 속성은 변경되지 않고 그대로 유지됩니다. 이 사용법에서 접두사는 클래스의 전체(대소문자 구분) 네임스페이스여야 합니다.

Config\App.forceGlobalSecureRequests = true
Config\App.CSPEnabled = true

참고

네임스페이스 접두사와 속성 이름은 모두 대소문자를 구분합니다. 구성 클래스 파일에 정의된 전체 네임스페이스 및 속성 이름과 정확히 일치해야 합니다.

구성 클래스 이름의 소문자 버전만 사용하는 네임스페이스인 short prefix의 경우에도 마찬가지입니다. 짧은 접두사가 클래스 이름과 일치하면 .env의 값이 구성 파일 값을 대체합니다.

app.forceGlobalSecureRequests = true
app.CSPEnabled = true

v4.1.5부터는 밑줄로도 작성할 수 있습니다.

app_forceGlobalSecureRequests = true
app_CSPEnabled = true

참고

short prefix을 사용할 때 속성 이름은 클래스에 정의된 이름과 정확히 일치해야 합니다.

데이터를 대체하는 환경 변수

.env에 포함된 환경 변수는 only replacements for existing scalar values이라는 점을 항상 기억하는 것이 매우 중요합니다.

간단히 말해서, .env에서 설정하여 Config 클래스에 존재하는 속성의 스칼라 값만 변경할 수 있습니다.

1. Config 클래스에 정의되지 않은 속성은 추가할 수 없습니다.

2. 속성의 스칼라 값을 배열로 변경할 수 없습니다.

3. 기존 배열에는 요소를 추가할 수 없습니다.

예를 들어, app.myNewConfig = foo을 .env에 넣고 Config\App가 마술처럼 런타임에 해당 속성과 값을 갖기를 기대할 수는 없습니다.

Config\Database에 $default = ['encrypt' => false] 속성이 있으면 .env에 database.default.encrypt.ssl_verify = true을 넣어도 encrypt 값을 배열로 변경할 수 없습니다. 그렇게 하고 싶다면 Database Configuration을 참조하세요.

환경 변수를 배열로 처리

네임스페이스 환경 변수는 추가로 배열로 처리될 수 있습니다. 접두사가 구성 클래스와 일치하는 경우 환경 변수 이름의 나머지 부분에도 점이 포함되어 있으면 배열 참조로 처리됩니다.

// regular namespaced variable
Config\SimpleConfig.name = George

// array namespaced variables
Config\SimpleConfig.address.city = "Berlin"
Config\SimpleConfig.address.country = "Germany"

이것이 SimpleConfig 구성 객체를 참조하는 경우 위 예는 다음과 같이 처리됩니다.

<?php

$address['city']    = 'Berlin';
$address['country'] = 'Germany';

$address 속성의 다른 요소는 변경되지 않습니다.

배열 속성 이름을 접두사로 사용할 수도 있습니다. 환경 파일에 다음이 포함되어 있으면 결과는 위와 동일합니다.

// array namespaced variables
Config\SimpleConfig.address.city = "Berlin"
address.country = "Germany"

다양한 환경 처리

해당 환경의 요구 사항에 맞게 값이 수정된 별도의 .env 파일을 사용하면 여러 환경을 쉽게 구성할 수 있습니다.

파일에는 애플리케이션에서 사용하는 모든 구성 클래스에 대해 가능한 모든 설정이 포함되어서는 안 됩니다. 실제로 환경에 특정한 항목이나 비밀번호, API 키, 기타 노출되어서는 안 되는 정보와 같은 민감한 세부 정보만 포함해야 합니다. 그러나 배포 간에 변경되는 모든 사항은 공정한 게임입니다.

각 환경에서 .env 파일을 프로젝트의 루트 폴더에 배치합니다. 대부분의 설정에서 이는 app 디렉터리와 동일한 수준입니다.

버전 관리 시스템으로 .env 파일을 추적하지 마세요. 그렇게 하고 저장소가 공개되면 모든 사람이 찾을 수 있는 민감한 정보를 보관하게 됩니다.

등록기관

“등록자”는 추가 구성 속성을 제공할 수 있는 다른 클래스입니다. 등록자는 런타임 시 네임스페이스와 파일 전반에 걸쳐 구성을 변경하는 수단을 제공합니다.

Modules에서 자동 검색이 활성화된 경우 등록 기관이 작동합니다. Config 객체가 인스턴스화될 때 구성 속성을 변경합니다.

참고

이 기능은 CodeIgniter\Config\BaseConfig 클래스에서 구현됩니다. 따라서 클래스를 확장하지 않는 app/Config 폴더의 일부 파일에서는 작동하지 않습니다.

등록자를 구현하는 방법에는 implicit 및 explicit의 두 가지 방법이 있습니다.

참고

.env의 값은 항상 등록자보다 우선합니다.

암시적 등록자

암시적 등록자는 모든 구성 클래스 속성을 변경할 수 있습니다.

모든 네임스페이스는 Config/Registrar.php 파일을 사용하여 암시적 등록자를 정의할 수 있습니다. 이러한 파일은 확장하려는 각 구성 클래스에 대해 메서드 이름이 지정된 클래스입니다.

예를 들어, 타사 모듈이나 Composer 패키지는 개발자가 이미 구성한 내용을 덮어쓰지 않고 Config\Pager에 추가 템플릿을 제공하려고 할 수 있습니다. src/Config/Registrar.php에는 단일 Pager() 메서드가 있는 Registrar 클래스가 있습니다(대소문자 구분 참고).

<?php

namespace CodeIgniter\Shield\Config;

class Registrar
{
    public static function Pager(): array
    {
        return [
            'templates' => [
                'module_pager' => 'MyModule\Views\Pager',
            ],
        ];
    }
}

등록자 메서드는 항상 대상 구성 파일의 속성에 해당하는 키와 함께 배열을 반환해야 합니다. 기존 값은 병합되고 등록자 속성은 덮어쓰기 우선순위를 가집니다.

명시적 등록자

명시적 등록자는 자신이 등록된 Config 클래스 속성만 변경할 수 있습니다.

구성 파일은 명시적으로 원하는 만큼의 등록자를 지정할 수도 있습니다. 이는 후보 등록기관의 이름 배열을 보유하는 구성 파일에 $registrars 속성을 추가하여 수행됩니다.

<?php

namespace Config;

// ...

class MyConfig extends BaseConfig
{
    public static $registrars = [
        SupportingPackageRegistrar::class,
    ];

    // ...
}

이렇게 식별된 클래스가 “등록자” 역할을 하려면 구성 클래스와 동일한 이름을 가진 정적 함수가 있어야 하며 속성 설정의 연관 배열을 반환해야 합니다.

구성 개체가 인스턴스화되면 $registrars의 지정된 클래스를 반복합니다. 이러한 각 클래스에 대해 구성 클래스에 대해 명명된 메서드를 호출하고 반환된 속성을 통합합니다.

이에 대한 샘플 구성 클래스 설정은 다음과 같습니다.

<?php

namespace Config;

use CodeIgniter\Config\BaseConfig;

class MySalesConfig extends BaseConfig
{
    public int $target        = 100;
    public string $campaign   = 'Winter Wonderland';
    public static $registrars = [
        '\App\Models\RegionalSales',
    ];
}

… 관련 지역 판매 모델은 다음과 같습니다.

<?php

namespace App\Models;

class RegionalSales
{
    public static function MySalesConfig(): array
    {
        return [
            'target' => 45,
        ];
    }
}

위의 예에서 MySalesConfig이 인스턴스화되면 세 가지 속성이 선언되지만 $target 속성의 값은 RegionalSales을 “등록자”로 처리하여 재정의됩니다. 결과 구성 속성은 다음과 같습니다.

<?php

$target   = 45;
$campaign = 'Winter Wonderland';

구성 값 확인

실제 Config 객체 속성 값은 런타임 시 등록기관, Environment Variables 및 Config Caching에 의해 변경됩니다.

CodeIgniter에는 실제 Config 값을 확인하기 위해 다음과 같은 command이 있습니다.

구성:확인

Added in version 4.5.0.

예를 들어, Config\App 인스턴스를 확인하려면 다음을 수행하세요.

php spark config:check App

출력은 다음과 같습니다.

Config\App#6 (12) (
    public 'baseURL' -> string (22) "http://localhost:8080/"
    public 'allowedHostnames' -> array (0) []
    public 'indexPage' -> string (9) "index.php"
    public 'uriProtocol' -> string (11) "REQUEST_URI"
    public 'defaultLocale' -> string (2) "en"
    public 'negotiateLocale' -> boolean false
    public 'supportedLocales' -> array (1) [
        0 => string (2) "en"
    ]
    public 'appTimezone' -> string (3) "UTC"
    public 'charset' -> string (5) "UTF-8"
    public 'forceGlobalSecureRequests' -> boolean false
    public 'proxyIPs' -> array (0) []
    public 'CSPEnabled' -> boolean false
)

Config Caching: Disabled

구성 캐싱이 활성화되어 있는지 여부를 확인할 수 있습니다.

참고

구성 캐싱이 활성화되면 캐시된 값이 영구적으로 사용됩니다. 자세한 내용은 Config Caching을 참조하세요.