Installation instructions for HAProxy
=====================================
HAProxy 2.6 is a long-term supported version, which means that it will get
fixes for bugs as they are discovered till around Q2 2027 and will not receive
new features. This version is suitable for general deployment as it is expected
to receive less frequent updates than regular stable branches which have an odd
digit in the minor version number. New users are encouraged to use long-term
supported versions such as the ones provided by their software vendor, Linux
distribution, or by a trusted package maintainer. Experienced users who manage
a fleet of load balancers are encouraged to deploy at least one node with the
latest weekly development version to get familiar with upcoming changes and
possibly detect unwelcome changes or bugs before the release. This is also a
great way to get new features implemented exactly as needed.
HAProxy 2.6은 장기적으로 지원되는 버전입니다. 즉, 2027년 2분기 경까지 발견된 버그에
대한 수정 사항이 제공되며 새로운 기능은 제공되지 않습니다.
이 버전은 부 버전 번호에 홀수가 있는 일반 안정 분기보다 업데이트를 덜 자주 받을 것으로
예상되므로 일반 배포에 적합합니다.
신규 사용자는 소프트웨어 공급업체, Linux 배포판 또는 신뢰할 수 있는 패키지 관리자가
제공하는 것과 같은 장기 지원 버전을 사용하는 것이 좋습니다.
로드 밸런서를 관리하는 숙련된 사용자는 최신 주간 개발 버전이 포함된 노드를 하나 이상
배포하여 향후 변경 사항에 익숙해지고 릴리스 전에 원치 않는 변경 사항이나 버그를 감지할
수 있습니다.
이것은 또한 필요에 따라 정확하게 구현되는 새로운 기능을 얻을 수 있는 좋은 방법입니다.
If for any reason you would prefer a different version than the one packaged
for your system, you want to be certain to have all the fixes or to get some
commercial support, other choices are available at http://www.haproxy.com/.
어떤 이유로든 시스템에 패키지된 버전과 다른 버전을 선호하거나 모든 수정 사항을
확인하거나 일부 상업적 지원을 받고 싶다면 http://www.haproxy.com/에서 다른 선택
사항을 사용할 수 있습니다. .
Areas covered in this document
이 문서에서 다루는 영역
==============================
1) Quick build & install 빠른 빌드 및 설치
2) Basic principles 기본 원칙
3) Build environment 환경 구축
4) Dependencies 종속성
5) Advanced build options 고급 빌드 옵션
6) How to install HAProxy HAProxy 설치 방법
================================
1) Quick build & install 빠른 빌드 및 설치
========================
If you've already built HAProxy and are just looking for a quick reminder, here
are a few build examples :
이미 HAProxy를 빌드했고 빠른 알림을 찾고 있다면 다음과 같은 몇 가지 빌드 예가 있습니다.
- recent Linux system with all options, make and install :
모든 옵션이 있는 최신 Linux 시스템을 만들고 설치하십시오.
$ make clean
$ make -j $(nproc) TARGET=linux-glibc USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1 USE_SYSTEMD=1
$ sudo make install
- FreeBSD and OpenBSD, build with all options :
$ gmake -j 4 TARGET=freebsd USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1
- embedded Linux, build using a cross-compiler :
$ make -j $(nproc) TARGET=linux-glibc USE_OPENSSL=1 USE_PCRE=1 \
CC=/opt/cross/gcc730-arm/bin/gcc ADDLIB=-latomic
- Build with static PCRE on Solaris / UltraSPARC :
$ make TARGET=solaris CPU=ultrasparc USE_STATIC_PCRE=1
For more advanced build options or if a command above reports an error, please
read the following sections.
고급 빌드 옵션이 필요하거나 위의 명령이 오류를 보고하는 경우 다음 섹션을 읽으십시오.
2) Basic principles
===================
HAProxy uses a single GNU Makefile which supports options on the command line,
so that there is no need to hack a "configure" file to work on your system. The
makefile totally supports parallel build using "make -j " where
matches the number of usable processors, which on some platforms is returned by
the "nproc" utility. The explanations below may occasionally refer to some
options, usually in the form "name=value", which have to be passed to the
command line. This means that the option has to be passed after the "make"
command. For example :
HAProxy는 명령줄에서 옵션을 지원하는 단일 GNU Makefile을 사용하므로 시스템에서
작동하기 위해 "구성" 파일을 해킹할 필요가 없습니다.
makefile은 "make -j "를 사용하여 병렬 빌드를 완전히 지원합니다.
여기서 는 사용 가능한 프로세서 수와 일치하며 일부 플랫폼에서는 "nproc"
유틸리티에 의해 반환됩니다.
아래 설명은 때때로 명령줄에 전달되어야 하는 "이름=값" 형식의 일부 옵션을 참조할 수 있습니다.
이것은 "make" 명령 다음에 옵션을 전달해야 함을 의미합니다. 예를 들어 :
$ make -j $(nproc) TARGET=generic USE_GZIP=1
One required option is TARGET, it must be set to a target platform name, which
provides a number of presets. The list of known platforms is displayed when no
target is specified. It is not strictly required to use the exact target, you
can use a relatively similar one and adjust specific variables by hand.
필수 옵션 중 하나는 TARGET이며 여러 사전 설정을 제공하는 대상 플랫폼 이름으로
설정해야 합니다. 대상이 지정되지 않은 경우 알려진 플랫폼 목록이 표시됩니다.
꼭 정확한 타겟을 사용해야 하는 것은 아니며, 비교적 유사한 타겟을 사용하여 손으로
특정 변수를 조정할 수 있습니다.
Most configuration variables are in fact booleans. Some options are detected and
enabled by default if available on the target platform. This is the case for all
those named "USE_". These booleans are enabled by "USE_=1"
and are disabled by "USE_=" (with no value). An exhaustive list of the
supported USE_* features is located at the top of the main Makefile. The last
occurrence of such an option on the command line overrides any previous one.
Example :
대부분의 구성 변수는 사실 부울입니다. 일부 옵션은 대상 플랫폼에서 사용 가능한
경우 기본적으로 감지되고 활성화됩니다.
이름이 "USE_"인 모든 경우에 해당합니다.
이러한 부울은 "USE_=1"에 의해 활성화되고 "USE_="(값 없음)에
의해 비활성화됩니다.
지원되는 USE_* 기능의 전체 목록은 기본 Makefile의 상단에 있습니다.
명령줄에서 이러한 옵션이 마지막으로 나타나면 이전 옵션보다 우선 적용됩니다.
예시 :
$ make TARGET=generic USE_THREAD=
In case of error or missing TARGET, a help screen is displayed. It is also
possible to display a list of all known options using "make help".
TARGET에 오류가 있거나 누락된 경우 도움말 화면이 표시됩니다.
"도움말 만들기"를 사용하여 알려진 모든 옵션 목록을 표시할 수도 있습니다.
Some optional components which may depend on third-party libraries, are used
with popular tools which are not necessarily standard implementations, or are
maintained at slower pace than the core of the project, are located in the
"addons/" directory. These ones may disappear in a future version if the
product they depend on disappears or if their maintainers do not assign enough
resources to maintain them any more. For this reason they are not built by
default, but some USE_* options are usually provided for them, and their build
is routinely tested anyway.
타사 라이브러리에 의존할 수 있는 일부 선택적 구성 요소는 반드시 표준 구현이
아니거나 프로젝트의 핵심보다 느린 속도로 유지되는 인기 있는 도구와 함께 사용되며
"addons/" 디렉토리에 있습니다.
의존하는 제품이 사라지거나 유지 관리 담당자가 더 이상 유지 관리하기에 충분한
리소스를 할당하지 않으면 향후 버전에서 사라질 수 있습니다.
이러한 이유로 기본적으로 빌드되지 않지만 일반적으로 일부 USE_* 옵션이 제공되며
빌드는 일상적으로 테스트됩니다.
3) Build environment
====================
HAProxy requires a working GCC or Clang toolchain and GNU make :
HAProxy는 작동하는 GCC 또는 Clang 도구 체인 및 GNU make가 필요합니다.
- GNU make >= 3.80. Note that neither Solaris nor OpenBSD's make work with
the GNU Makefile. If you get many syntax errors when running "make", you
may want to retry with "gmake" which is the name commonly used for GNU make
on BSD systems.
- GNU는 >= 3.80을 만듭니다. Solaris나 OpenBSD의 make는 GNU Makefile과 함께
작동하지 않습니다.
"make"를 실행할 때 많은 구문 오류가 발생하면 BSD 시스템에서 GNU make에
일반적으로 사용되는 이름인 "gmake"로 다시 시도할 수 있습니다.
- GCC >= 4.2 (up to 12 tested). Older versions can be made to work with a
few minor adaptations if really needed. Newer versions may sometimes break
due to compiler regressions or behaviour changes. The version shipped with
your operating system is very likely to work with no trouble. Clang >= 3.0
is also known to work as an alternative solution. Recent versions may emit
a bit more warnings that are worth reporting as they may reveal real bugs.
TCC (https://repo.or.cz/tinycc.git) is also usable for developers but will
not support threading and was found at least once to produce bad code in
some rare corner cases (since fixed). But it builds extremely quickly
(typically half a second for the whole project) and is very convenient to
run quick tests during API changes or code refactoring.
- GCC >= 4.2(최대 12개 테스트).
이전 버전은 실제로 필요한 경우 몇 가지 사소한 조정으로 작동하도록 만들 수 있습니다.
최신 버전은 때때로 컴파일러 회귀 또는 동작 변경으로 인해 중단될 수 있습니다.
운영 체제와 함께 제공된 버전은 문제 없이 작동할 가능성이 매우 높습니다.
Clang >= 3.0도 대안 솔루션으로 작동하는 것으로 알려져 있습니다.
최신 버전은 실제 버그를 드러낼 수 있으므로 보고할 가치가 있는 경고를 조금 더
내보낼 수 있습니다.
TCC(https://repo.or.cz/tinycc.git)는 개발자도 사용할 수 있지만 스레딩을 지원하지
않으며 드문 경우(고정 이후)에서 잘못된 코드를 생성하는 것으로 적어도 한 번 발견되었습니다.
그러나 매우 빠르게 빌드되며(일반적으로 전체 프로젝트의 경우 0.5초) API 변경 또는
코드 리팩토링 중에 빠른 테스트를 실행하는 것이 매우 편리합니다.
- GNU ld (binutils package), with no particular version. Other linkers might
work but were not tested.
- 특정 버전이 없는 GNU ld(binutils 패키지).
다른 링커는 작동할 수 있지만 테스트되지 않았습니다.
On debian or Ubuntu systems and their derivatives, you may get all these tools
at once by issuing the two following commands :
데비안 또는 우분투 시스템과 그 파생물에서 다음 두 명령을 실행하여 이러한 모든
도구를 한 번에 얻을 수 있습니다.
$ sudo apt-get update
$ sudo apt-get install build-essential
On Fedora, CentOS, RHEL and derivatives, you may get the equivalent packages
with the following command :
Fedora, CentOS, RHEL 및 파생 제품에서 다음 명령을 사용하여 동등한 패키지를
얻을 수 있습니다.
$ sudo yum groupinstall "Development Tools"
Please refer to your operating system's documentation for other systems.
It is also possible to build HAProxy for another system or platform using a
cross-compiler but in this case you probably already have installed these
tools.
Building HAProxy may require between 60 and 80 MB of free space in the
directory where the sources have been extracted, depending on the debugging
options involved.
다른 시스템에 대한 운영 체제 설명서를 참조하십시오.
크로스 컴파일러를 사용하여 다른 시스템 또는 플랫폼용 HAProxy를 구축할 수도 있지만
이 경우에는 이미 이러한 도구를 설치했을 수 있습니다.
HAProxy를 빌드하려면 관련된 디버깅 옵션에 따라 소스가 추출된 디렉토리에 60MB에서
80MB 사이의 여유 공간이 필요할 수 있습니다.
4) Dependencies
===============
HAProxy in its basic form does not depend on anything beyond a working libc.
However a number of options are enabled by default, or are highly recommended,
and these options will typically involve some external components or libraries,
depending on the targeted platform.
기본 형태의 HAProxy는 작동하는 libc 이외의 것에 의존하지 않습니다.
그러나 많은 옵션이 기본적으로 활성화되어 있거나 적극 권장되며 이러한 옵션에는
일반적으로 대상 플랫폼에 따라 일부 외부 구성 요소 또는 라이브러리가 포함됩니다.
Optional dependencies may be split into several categories :
선택적 종속성은 여러 범주로 나눌 수 있습니다.
- memory allocation 메모리 할당
- regular expressions 정규식
- multi-threading 멀티 스레딩
- password encryption 비밀번호 암호화
- cryptography 암호화 OpenSSL
- compression 압축
- lua
- device detection 장치 감지
- miscellaneous
4.1) Memory allocation
----------------------
By default, HAProxy uses the standard malloc() call provided by the libc. It
may also be built to use jemalloc, which is fast and thread-safe. In order to
use it, please add "-ljemalloc" to the ADDLIB variable. You may possibly also
need to append "-lpthread" and/or "-ldl" depending on the operating system.
기본적으로 HAProxy는 libc에서 제공하는 표준 malloc() 호출을 사용합니다.
빠르고 스레드로부터 안전한 jemalloc을 사용하도록 구축될 수도 있습니다.
사용하기 위해서는 ADDLIB 변수에 "-ljemalloc"을 추가해 주세요.
운영 체제에 따라 "-lpthread" 및/또는 "-ldl"을 추가해야 할 수도 있습니다.
4.2) Regular expressions
------------------------
HAProxy may make use regular expressions (regex) to match certain patterns. The
regex engine is provided by default in the libc. On some operating systems, it
might happen that the original regex library provided by the libc is too slow,
too limited or even bogus. For example, on older Solaris versions up to 8, the
default regex used not to properly extract group references, without reporting
compilation errors. Also, some early versions of the GNU libc used to include a
regex engine which could be slow or even crash on certain patterns.
HAProxy는 정규식(regex)을 사용하여 특정 패턴을 일치시킬 수 있습니다.
정규식 엔진은 기본적으로 libc에서 제공됩니다.
일부 운영 체제에서는 libc가 제공하는 원래 정규식 라이브러리가 너무 느리거나
너무 제한적이거나 가짜일 수 있습니다.
예를 들어, 이전 Solaris 버전 8 이하에서 기본 정규식은 컴파일 오류를 보고하지 않고
그룹 참조를 제대로 추출하지 않는 데 사용되었습니다.
또한 GNU libc의 일부 초기 버전에는 특정 패턴에서 느리거나 충돌이 발생할 수 있는
정규식 엔진이 포함되어 있었습니다.
If you plan on importing a particularly heavy configuration involving a lot of
regex, you may benefit from using some alternative regex implementations such as
PCRE. HAProxy natively supports PCRE and PCRE2, both in standard and JIT
flavors (Just In Time). The following options are available depending on the
library version provided on your system :
많은 정규식을 포함하는 특히 무거운 구성을 가져올 계획이라면 PCRE와 같은 일부 대체
정규식 구현을 사용하는 것이 좋습니다.
HAProxy는 기본적으로 표준 및 JIT 버전(Just In Time) 모두에서 PCRE 및 PCRE2를 지원합니다.
시스템에 제공된 라이브러리 버전에 따라 다음 옵션을 사용할 수 있습니다.
(Perl Compatible Regular Expressions, PCRE)
- "USE_PCRE=1" : enable PCRE version 1, dynamic linking
- "USE_STATIC_PCRE=1" : enable PCRE version 1, static linking
- "USE_PCRE_JIT=1" : enable PCRE version 1 in JIT mode
- "USE_PCRE2=1" : enable PCRE version 2, dynamic linking
- "USE_STATIC_PCRE2=1" : enable PCRE version 2, static linking
- "USE_PCRE2_JIT=1" : enable PCRE version 2 in JIT mode
Both of these libraries may be downloaded from https://www.pcre.org/.
By default, the include and library paths are figured from the "pcre-config"
and "pcre2-config" utilities. If these ones are not installed or inaccurate
(for example when cross-compiling), it is possible to force the path to include
files using "PCRE_INC" and "PCRE2_INC" respectively, and the path to library
files using "PCRE_LIB" and "PCRE2_LIB" respectively. For example :
기본적으로 포함 및 라이브러리 경로는 "pcre-config" 및 "pcre2-config" 유틸리티에서 계산됩니다.
이러한 파일이 설치되지 않았거나 정확하지 않은 경우(예: 크로스 컴파일 시) 각각 "PCRE_INC" 및
"PCRE2_INC"를 사용하여 파일을 포함하고 "PCRE_LIB" 및 "PCRE2_LIB"를 사용하여 라이브러리 파일
경로를 강제로 포함할 수 있습니다. " 각각. 예를 들어 :
$ make TARGET=generic \
USE_PCRE2_JIT=1 PCRE2_INC=/opt/cross/include PCRE2_LIB=/opt/cross/lib
4.3) Multi-threading
--------------------
On some systems for which positive feedback was reported, multi-threading will
be enabled by default. When multi-threading is used, the libpthread library
(POSIX threading) will be used. If the target system doesn't contain such a
library, it is possible to forcefully disable multi-threading by adding
"USE_THREAD=" on the command line.
긍정적인 피드백이 보고된 일부 시스템에서는 기본적으로 멀티스레딩이 활성화됩니다.
멀티 스레딩을 사용하는 경우 libpthread 라이브러리(POSIX 스레딩)가 사용됩니다.
대상 시스템에 이러한 라이브러리가 없으면 명령줄에 "USE_THREAD="를 추가하여
다중 스레딩을 강제로 비활성화할 수 있습니다.
4.4) Password encryption
------------------------
Many systems provide password encryption functions used for authentication. On
some systems these functions are part of the libc. On others, they're part of a
separate library called "libcrypt". The default targets are pre-configured
based on which system needs the library. It is possible to forcefully disable
the linkage against libcrypt by adding "USE_LIBCRYPT=" on the command line, or
to forcefully enable it using "USE_LIBCRYPT=1".
많은 시스템에서 인증에 사용되는 암호 암호화 기능을 제공합니다.
일부 시스템에서 이러한 기능은 libc의 일부입니다.
다른 것들은 "libcrypt"라는 별도 라이브러리의 일부입니다.
기본 대상은 라이브러리가 필요한 시스템에 따라 미리 구성됩니다.
명령줄에 "USE_LIBCRYPT="를 추가하여 libcrypt에 대한 연결을 강제로 비활성화하거나
"USE_LIBCRYPT=1"을 사용하여 강제로 활성화할 수 있습니다.
4.5) Cryptography
-----------------
For SSL/TLS, it is necessary to use a cryptography library. HAProxy currently
supports the OpenSSL library, and is known to build and work with branches
1.0.0, 1.0.1, 1.0.2, 1.1.0, 1.1.1, and 3.0.x. OpenSSL follows a long-term
support cycle similar to HAProxy's, and each of the branches above receives its
own fixes, without forcing you to upgrade to another branch. There is no excuse
for staying vulnerable by not applying a fix available for your version. There
is always a small risk of regression when jumping from one branch to another
one, especially when it's very new, so it's preferable to observe for a while
if you use a different version than your system's defaults.
SSL/TLS의 경우 암호화 라이브러리를 사용해야 합니다.
HAProxy는 현재 OpenSSL 라이브러리를 지원하며 분기 1.0.0, 1.0.1, 1.0.2, 1.1.0, 1.1.1 및
3.0.x를 빌드하고 작동하는 것으로 알려져 있습니다. OpenSSL은 HAProxy와 유사한 장기 지원 주기를
따르며 위의 각 분기는 다른 분기로 업그레이드하지 않고도 자체 수정 사항을 받습니다.
귀하의 버전에 사용 가능한 수정 사항을 적용하지 않음으로써 취약한 상태를 유지하는 것에
대한 변명의 여지가 없습니다.
한 브랜치에서 다른 브랜치로 이동할 때, 특히 매우 새로운 브랜치로 이동할 때 항상 약간의
회귀 위험이 있으므로 시스템의 기본값과 다른 버전을 사용하는 경우 잠시 관찰하는 것이 좋습니다.
Three OpenSSL derivatives called LibreSSL, BoringSSL and QUICTLS are reported
to work as well. While there are some efforts from the community to ensure they
work well, OpenSSL remains the primary target and this means that in case of
conflicting choices, OpenSSL support will be favored over other options. Note
that OpenSSL is not compatible when building haproxy with QUIC support. In this
case, QUICTLS is the preferred alternative. See the section about QUIC in this
document.
LibreSSL, BoringSSL 및 QUICTLS라는 세 가지 OpenSSL 파생 제품도 작동하는 것으로
보고되었습니다. 커뮤니티에서 제대로 작동하도록 하기 위한 몇 가지 노력이 있지만
OpenSSL은 여전히 주요 대상이며 이는 선택이 충돌하는 경우 OpenSSL 지원이
다른 옵션보다 우선한다는 것을 의미합니다.
OpenSSL은 QUIC 지원으로 haproxy를 빌드할 때 호환되지 않습니다.
이 경우 QUICTLS가 선호되는 대안입니다.
이 문서의 QUIC에 대한 섹션을 참조하십시오.
In order to enable SSL/TLS support, simply pass "USE_OPENSSL=1" on the command
line and the default library present on your system will be used :
SSL/TLS 지원을 활성화하려면 명령줄에서 "USE_OPENSSL=1"을 전달하기만 하면
시스템에 있는 기본 라이브러리가 사용됩니다.
$ make TARGET=generic USE_OPENSSL=1
If you want to use a different version from the one provided by your system
(which is not recommended due to the risk of missing security fixes), it is
possible to indicate the path to the SSL include files using SSL_INC, and the
SSL library files using SSL_LIB. Example :
시스템에서 제공하는 버전과 다른 버전을 사용하려는 경우(보안 수정 사항이 누락될
위험 때문에 권장하지 않음), SSL_INC를 사용하여 SSL 포함 파일 및 SSL 라이브러리
파일에 대한 경로를 지정할 수 있습니다. SSL_LIB를 사용합니다. 예시 :
$ make TARGET=generic \
USE_OPENSSL=1 SSL_INC=/opt/ssl-1.1.1/include SSL_LIB=/opt/ssl-1.1.1/lib
In order to link OpenSSL statically against HAProxy, first download OpenSSL
from https://www.openssl.org/ then build it with the "no-shared" keyword and
install it to a local directory, so your system is not affected :
HAProxy에 대해 OpenSSL을 정적으로 연결하려면 먼저 https://www.openssl.org/에서
OpenSSL을 다운로드한 다음 "no-shared" 키워드로 빌드하고 로컬 디렉토리에 설치하여
시스템이 영향을 받지 않도록 합니다.
$ export STATICLIBSSL=/tmp/staticlibssl
$ ./config --prefix=$STATICLIBSSL no-shared
$ make && make install_sw
Then when building haproxy, pass that path via SSL_INC and SSL_LIB :
그런 다음 haproxy를 빌드할 때 SSL_INC 및 SSL_LIB를 통해 해당 경로를 전달합니다.
$ make TARGET=generic \
USE_OPENSSL=1 SSL_INC=$STATICLIBSSL/include SSL_LIB=$STATICLIBSSL/lib
When building with OpenSSL on some systems, you may also need to enable support
for the "libz" library, which is visible if the linker complains about function
"deflateInit()" not being found. In this case, simply append "ADDLIB=-lz" to
the command line.
일부 시스템에서 OpenSSL을 사용하여 빌드할 때 "libz" 라이브러리에 대한 지원을
활성화해야 할 수도 있습니다. 이 라이브러리는 링커가 "deflateInit()" 함수를 찾을
수 없다고 불평하는 경우 표시됩니다.
이 경우 명령줄에 "ADDLIB=-lz"를 추가하기만 하면 됩니다.
It is worth mentioning that asynchronous cryptography engines are supported on
OpenSSL 1.1.0 and above. Such engines are used to access hardware cryptography
acceleration that might be present on your system. Due to API changes that
appeared with OpenSSL 3.0 and cause lots of build warnings, engines are not
enabled by default anymore in HAProxy 2.6. It is required to pass USE_ENGINE=1
if they are desired.
It is worth mentioning that asynchronous cryptography engines are supported on OpenSSL 1.1.0 and above.
Such engines are used to access hardware cryptography acceleration that might be present on your system.
Due to API changes that appeared with OpenSSL 3.0 and cause lots of build warnings, engines are not enabled by default anymore in HAProxy 2.6.
It is required to pass USE_ENGINE=1 if they are desired.
비동기식 암호화 엔진이 OpenSSL 1.1.0 이상에서 지원된다는 점은 언급할 가치가 있습니다.
이러한 엔진은 시스템에 있을 수 있는 하드웨어 암호화 가속에 액세스하는 데 사용됩니다.
OpenSSL 3.0과 함께 나타나고 많은 빌드 경고를 유발하는 API 변경으로 인해 HAProxy 2.6에서는
엔진이 더 이상 기본적으로 활성화되지 않습니다.
원하는 경우 USE_ENGINE=1을 전달해야 합니다.
4.6) Compression 압축
----------------
HAProxy can compress HTTP responses before delivering them to clients, in order
to save network bandwidth. Two compression options are available. The first one
relies on the libslz library (http://libslz.org) that is embedded in haproxy.
It is enabled by default as it is very fast and does not keep a copy of the
contents in memory. It is possible to disable it, for example for very small
systems, by passing "USE_SLZ=" to the "make" command.
HAProxy는 네트워크 대역폭을 절약하기 위해 HTTP 응답을 클라이언트에 전달하기 전에
압축할 수 있습니다. 두 가지 압축 옵션을 사용할 수 있습니다.
첫 번째는 haproxy에 포함된 libslz 라이브러리(http://libslz.org)에 의존합니다.
매우 빠르며 내용의 복사본을 메모리에 보관하지 않기 때문에 기본적으로 활성화되어 있습니다.
예를 들어 매우 작은 시스템의 경우 "make" 명령에 "USE_SLZ="를 전달하여 비활성화할 수 있습니다.
Please note that SLZ will benefit from some CPU-specific instructions like the
availability of the CRC32 extension on some ARM processors. Thus it can further
improve its performance to build with "CPU=native" on the target system, or
"CPU=armv81" (modern systems such as Graviton2 or A55/A75 and beyond),
"CPU=a72" (e.g. for RPi4, or AWS Graviton), "CPU=a53" (e.g. for RPi3), or
"CPU=armv8-auto" (automatic detection with minor runtime penalty).
SLZ는 일부 ARM 프로세서에서 CRC32 확장의 가용성과 같은 일부 CPU 관련 명령어의
이점을 얻을 수 있습니다.
따라서 대상 시스템에서 "CPU=native" 또는 "CPU=armv81"(Graviton2 또는 A55/A75
이상과 같은 최신 시스템), "CPU=a72"(예: RPi4의 경우, 또는 AWS Graviton),
"CPU=a53"(예: RPi3의 경우) 또는 "CPU=armv8-auto"(약간의 런타임 패널티가 있는 자동 감지).
A second option involves the widely known zlib library, which is very likely
installed on your system. In order to use zlib, simply pass "USE_ZLIB=1" to the
"make" command line, which will also automatically disable SLZ. If the library
is not installed in your default system's path, it is possible to specify the
path to the include files using ZLIB_INC, and the path to the library files
using ZLIB_LIB :
두 번째 옵션에는 널리 알려진 zlib 라이브러리가 포함되며 이는 시스템에 설치될 가능성이
매우 높습니다. zlib를 사용하려면 "make" 명령줄에 "USE_ZLIB=1"을 전달하기만 하면 됩니다.
그러면 SLZ도 자동으로 비활성화됩니다.
라이브러리가 기본 시스템의 경로에 설치되어 있지 않으면 ZLIB_INC를 사용하여 포함 파일의
경로를 지정하고 ZLIB_LIB를 사용하여 라이브러리 파일의 경로를 지정할 수 있습니다.
$ make TARGET=generic \
USE_ZLIB=1 ZLIB_INC=/opt/zlib-1.2.11/include ZLIB_LIB=/opt/zlib-1.2.11/lib
Zlib is commonly found on most systems, otherwise updates can be retrieved from
http://www.zlib.net/. It is easy and fast to build, and new versions sometimes
provide better performance so it might be worth using an up-to-date one.
Zlib는 대부분의 시스템에서 일반적으로 발견되며, 그렇지 않으면 http://www.zlib.net/에서
업데이트를 검색할 수 있습니다.
쉽고 빠르게 빌드할 수 있으며 새 버전은 때때로 더 나은 성능을 제공하므로 최신 버전을
사용할 가치가 있습니다.
Zlib compresses a bit better than libslz but at the expense of more CPU usage
(about 3.5 times more minimum), and a huge memory usage (~260 kB per compressed
stream). The only valid reason for uzing Zlib instead of SLZ here usually is to
deal with a very limited internet bandwidth while CPU and RAM are abundant so
that the last few percent of compression ratio are worth the invested hardware.
Zlib는 libslz보다 약간 더 압축하지만 더 많은 CPU 사용량(최소 약 3.5배 이상)과 막대한
메모리 사용량(압축된 스트림당 ~260kB)을 희생합니다.
여기에서 SLZ 대신 Zlib를 사용하는 유일한 타당한 이유는 일반적으로 CPU와 RAM이
풍부한 동안 매우 제한된 인터넷 대역폭을 처리하여 압축 비율의 마지막 몇 퍼센트가
투자된 하드웨어의 가치가 있도록 하기 위함입니다.
4.7) Lua
--------
Lua is an embedded programming language supported by HAProxy to provide more
advanced scripting capabilities. Only versions 5.3 and above are supported.
In order to enable Lua support, please specify "USE_LUA=1" on the command line.
Some systems provide this library under various names to avoid conflicts with
previous versions. By default, HAProxy looks for "lua5.4", "lua54", "lua5.3",
"lua53", "lua". If your system uses a different naming, you may need to set the
library name in the "LUA_LIB_NAME" variable.
Lua는 고급 스크립팅 기능을 제공하기 위해 HAProxy에서 지원하는 임베디드 프로그래밍
언어입니다. Lua 버전 5.3 이상만 지원됩니다.
Lua 지원을 활성화하려면 명령줄에서 "USE_LUA=1"을 지정하십시오.
일부 시스템은 이전 버전과의 충돌을 피하기 위해 다양한 이름으로 이 라이브러리를 제공합니다.
기본적으로 HAProxy는 "lua5.4", "lua54", "lua5.3", "lua53", "lua"를 찾습니다.
시스템에서 다른 이름을 사용하는 경우 "LUA_LIB_NAME" 변수에 라이브러리 이름을 설정해야
할 수 있습니다.
If Lua is not provided on your system, it can be very simply built locally. It
can be downloaded from https://www.lua.org/, extracted and built, for example :
Lua가 시스템에 제공되지 않으면 로컬에서 매우 간단하게 빌드할 수 있습니다.
https://www.lua.org/에서 다운로드하고 추출하여 빌드할 수 있습니다. 예를 들면 다음과 같습니다.
$ cd /opt/lua-5.3.5
$ make linux
The path to the include files and library files may be set using "LUA_INC" and
"LUA_LIB" respectively. For example :
포함 파일 및 라이브러리 파일의 경로는 각각 "LUA_INC" 및 "LUA_LIB"를 사용하여
설정할 수 있습니다. 예를 들어 :
$ make TARGET=generic \
USE_LUA=1 LUA_INC=/opt/lua-5.3.5/src LUA_LIB=/opt/lua-5.3.5/src
4.8) Device detection 장치 감지
---------------------
HAProxy supports several device detection modules relying on third party
products. Some of them may provide free code, others free libs, others free
evaluation licenses. Please read about their respective details in the
following files :
HAProxy는 타사 제품에 의존하는 여러 장치 감지 모듈을 지원합니다.
그들 중 일부는 무료 코드를 제공하고, 다른 일부는 무료 라이브러리를,
다른 일부는 무료 평가 라이선스를 제공할 수 있습니다.
다음 파일에서 해당 세부 정보를 읽으십시오.
doc/DeviceAtlas-device-detection.txt for DeviceAtlas
doc/51Degrees-device-detection.txt for 51Degrees
doc/WURFL-device-detection.txt for Scientiamobile WURFL
4.9) Miscellaneous 기타
------------------
Some systems have specificities. Usually these specificities are known and/or
detected and properly set for you. If you need to adjust the behaviour, here
are the extra libraries that may be referenced at build time :
일부 시스템에는 특수성이 있습니다.
일반적으로 이러한 특성은 알려지거나 감지되어 적절하게 설정됩니다.
동작을 조정해야 하는 경우 빌드 시 참조할 수 있는 추가 라이브러리는 다음과 같습니다.
- USE_RT=1 build with librt, which is sometimes needed on some systems
when using threads. It is set by default on Linux platforms,
and may be disabled using "USE_RT=" if your system doesn't
have one. You may have to set it as well if you face an error
indicating that clock_gettime() was not found.
스레드를 사용할 때 일부 시스템에서 때때로 필요한 librt로 빌드합니다.
Linux 플랫폼에서는 기본적으로 설정되며 시스템에 "USE_RT="가 없으면 비활성화할 수 있습니다.
clock_gettime()을 찾을 수 없다는 오류가 발생하는 경우에도 설정해야 할 수 있습니다.
- USE_DL=1 build with libdl, which is usually needed for Lua and OpenSSL
on Linux. It is automatically detected and may be disabled
using "USE_DL=", though it should never harm.
일반적으로 Linux의 Lua 및 OpenSSL에 필요한 libdl로 빌드합니다.
그것은 자동으로 감지되며 "USE_DL="을 사용하여 비활성화될 수 있지만
결코 해를 끼치지는 않습니다.
- USE_SYSTEMD=1 enables support for the sdnotify features of systemd,
allowing better integration with systemd on Linux systems
which come with it. It is never enabled by default so there
is no need to disable it.
systemd의 sdnotify 기능에 대한 지원을 활성화하여 함께 제공되는 Linux
시스템에서 systemd와 더 잘 통합할 수 있습니다.
기본적으로 활성화되어 있지 않으므로 비활성화할 필요가 없습니다.
4.10) Common errors
-------------------
Some build errors may happen depending on the options combinations or the
selected target. When facing build errors, if you know that your system is a
bit special or particularly old, start from TARGET=generic, it is easier to
start from there and fix the remaining issues than trying to degrade another
target. Common issues may include:
옵션 조합 또는 선택한 대상에 따라 일부 빌드 오류가 발생할 수 있습니다.
빌드 오류에 직면했을 때 시스템이 약간 특별하거나 특히 오래되었다는 것을 알고 있다면
TARGET=generic에서 시작하십시오. 다른 대상을 저하시키려고 시도하는 것보다 거기에서
시작하여 나머지 문제를 수정하는 것이 더 쉽습니다.
일반적인 문제는 다음과 같습니다.
- clock_gettime() not found
=> your system needs USE_RT=1
- many __sync_ errors in many files
=> your gcc is too old, build without threads.
gcc가 오래된 버전이니 스레드 없이 컴파일하세요.
- many openssl errors
=> your OpenSSL version really is too old, do not enable OpenSSL
OpenSSL이 진짜 오래된 버전이니 OpenSSL을 활성화하지 마세요.
4.11) QUIC
----------
QUIC is the new transport layer protocol and is required for HTTP/3. This
protocol stack is currently supported as an experimental feature in haproxy on
the frontend side. In order to enable it, use "USE_QUIC=1 USE_OPENSSL=1".
QUIC는 새로운 전송 계층 프로토콜이며 HTTP/3에 필요합니다.
이 프로토콜 스택은 현재 프론트엔드 측 haproxy의 실험적 기능으로 지원됩니다.
활성화하려면 "USE_QUIC=1 USE_OPENSSL=1"을 사용하십시오.
QUIC에 대한 일반적인 설명: https://ko.wikipedia.org/wiki/QUIC
QUIC: Quick UDP Internet Connections
Note that the OpenSSL library is not compatible with QUIC. The preferred option
is to use QUICTLS. This is a fork of OpenSSL with a QUIC-compatible API. Its
repository is available at https://github.com/quictls/openssl. You can use the
following instruction to build a functional QUICTLS.
OpenSSL 라이브러리는 QUIC와 호환되지 않습니다.
기본 옵션은 QUICTLS를 사용하는 것입니다.
이것은 QUIC 호환 API가 있는 OpenSSL의 포크입니다.
해당 저장소는 https://github.com/quictls/openssl에서 사용할 수 있습니다.
다음 지침을 사용하여 기능적인 QUICTLS를 빌드할 수 있습니다.
$ ./config --libdir=lib [--prefix=/opt/quictls]
$ make
$ make install
On a development environment, use SSL_INC and SSL_LIB when building haproxy to
point to the correct cryptographic library. It may be useful to specify QUICTLS
location via rpath for haproxy execution. Example :
개발 환경에서 올바른 암호화 라이브러리를 가리키도록 haproxy를 빌드할 때 SSL_INC 및
SSL_LIB를 사용합니다.
haproxy 실행을 위해 rpath를 통해 QUICTLS 위치를 지정하는 것이 유용할 수 있습니다.
예시 :
$ make TARGET=generic \
USE_QUIC=1 \
USE_OPENSSL=1 SSL_INC=/opt/quictls/include SSL_LIB=/opt/quictls/lib \
LDFLAGS="-Wl,-rpath,/opt/quictls/lib"
5) How to build HAProxy
=======================
This section assumes that you have already read section 2 (basic principles)
and section 3 (build environment). It often refers to section 4 (dependencies).
이 섹션에서는 섹션 2(기본 원칙)와 섹션 3(빌드 환경)을 이미 읽었다고 가정합니다.
종종 섹션 4(종속성)를 참조합니다.
To build haproxy, you have to choose your target OS amongst the following ones
and assign it to the TARGET variable :
haproxy를 빌드하려면 다음 중에서 대상 OS를 선택하고 TARGET 변수에 할당해야 합니다.
- linux-glibc for Linux kernel 2.6.28 and above
- linux-glibc-legacy for Linux kernel 2.6.28 and above without new features
- linux-musl for Linux kernel 2.6.28 and above with musl libc
- solaris for Solaris 10 and above
- freebsd for FreeBSD 10 and above
- dragonfly for DragonFlyBSD 4.3 and above
- netbsd for NetBSD 8 and above
- osx for Mac OS/X
- openbsd for OpenBSD 6.3 and above
- aix51 for AIX 5.1
- aix52 for AIX 5.2
- aix72-gcc for AIX 7.2 (using gcc)
- cygwin for Cygwin
- haiku for Haiku
- generic for any other OS or version.
- custom to manually adjust every setting
You may also choose your CPU to benefit from some optimizations. This is
particularly important on UltraSparc machines. For this, you can assign
one of the following choices to the CPU variable :
일부 최적화의 이점을 얻기 위해 CPU를 선택할 수도 있습니다.
이는 UltraSparc 장비에서 특히 중요합니다.
이를 위해 다음 선택 사항 중 하나를 CPU 변수에 할당할 수 있습니다.
- i686 for intel PentiumPro, Pentium 2 and above, AMD Athlon (32 bits)
- i586 for intel Pentium, AMD K6, VIA C3.
- ultrasparc : Sun UltraSparc I/II/III/IV processor
- power8 : IBM POWER8 processor
- power9 : IBM POWER9 processor
- armv81 : modern ARM cores (Cortex A55/A75/A76/A78/X1, Neoverse, Graviton2)
- a72 : ARM Cortex-A72 or A73 (e.g. RPi4, Odroid N2, AWS Graviton)
- a53 : ARM Cortex-A53 or any of its successors in 64-bit mode (e.g. RPi3)
- armv8-auto : support both older and newer armv8 cores with a minor penalty,
thanks to gcc 10's outline atomics (default with gcc 10.2).
- native : use the build machine's specific processor optimizations. Use with
extreme care, and never in virtualized environments (known to break).
빌드 머신의 특정 프로세서 최적화를 사용합니다.
극도의 주의를 기울여 사용하고 가상화된 환경(파손되는 것으로 알려짐)에서는
절대 사용하지 마십시오.
- generic : any other processor or no CPU-specific optimization. (default)
기타 프로세서 또는 CPU별 최적화 없음. (기본)
Alternatively, you may just set the CPU_CFLAGS value to the optimal GCC options
for your platform. A second variable named SMALL_OPTS also supports passing a
number of defines and compiler options usually for small systems. For better
clarity it's recommended to pass the options which result in a smaller binary
(like memory limits or -Os) into this variable.
또는 CPU_CFLAGS 값을 플랫폼에 대한 최적의 GCC 옵션으로 설정할 수 있습니다.
SMALL_OPTS라는 두 번째 변수는 일반적으로 소규모 시스템에 대한 많은 정의 및 컴파일러
옵션 전달을 지원합니다. 더 명확하게 하기 위해 더 작은 바이너리(메모리 제한 또는 -O와 같은)를
초래하는 옵션을 이 변수에 전달하는 것이 좋습니다.
If you are building for a different system than the one you're building on,
this is called "cross-compiling". HAProxy supports cross-compilation pretty
well and tries to ease it by letting you adjust paths to all libraries (please
read section 4 on dependencies for more details). When cross-compiling, you
just need to pass the path to your compiler in the "CC" variable, and the path
to the linker in the "LD" variable. Most of the time, setting the CC variable
is enough since LD points to it by default.
구축 중인 시스템과 다른 시스템용으로 구축하는 경우 이를 "크로스 컴파일"이라고 합니다.
HAProxy는 교차 컴파일을 매우 잘 지원하며 모든 라이브러리에 대한 경로를 조정할 수 있도록
하여 쉽게 만들려고 합니다(자세한 내용은 종속성에 대한 섹션 4 참조).
크로스 컴파일할 때 "CC" 변수의 컴파일러 경로와 "LD" 변수의 링커 경로만 전달하면 됩니다.
대부분의 경우 LD가 기본적으로 CC 변수를 가리키므로 CC 변수를 설정하면 충분합니다.
By default the build process runs in quiet mode and hide the details of the
commands that are executed. This allows to more easily catch build warnings
and see what is happening. However it is not convenient at all to observe what
flags are passed to the compiler nor what compiler is involved. Simply append
"V=1" to the "make" command line to switch to verbose mode and display the
details again. It is recommended to use this option when cross-compiling to
verify that the paths are correct and that /usr/include is never invovled.
기본적으로 빌드 프로세스는 자동 모드에서 실행되고 실행되는 명령의 세부 정보를 숨깁니다.
이를 통해 빌드 경고를 보다 쉽게 포착하고 무슨 일이 일어나고 있는지 확인할 수 있습니다.
그러나 어떤 플래그가 컴파일러에 전달되고 어떤 컴파일러가 관련되어 있는지 관찰하는 것은
전혀 편리하지 않습니다.
"make" 명령줄에 "V=1"을 추가하기만 하면 자세한 정보 표시 모드로 전환하고 세부 정보를
다시 표시할 수 있습니다.
경로가 정확하고 /usr/include가 절대 관련되지 않았는지 확인하기 위해 크로스 컴파일할 때
이 옵션을 사용하는 것이 좋습니다.
You may want to build specific target binaries which do not match your native
compiler's target. This is particularly true on 64-bit systems when you want
to build a 32-bit binary. Use the ARCH variable for this purpose. Right now
it only knows about a few x86 variants (i386,i486,i586,i686,x86_64), two
generic ones (32,64) and sets -m32/-m64 as well as -march= accordingly.
This variable is only used to set ARCH_FLAGS to preset values, so if you know
the arch-specific flags that your system needs, you may prefer to set
ARCH_FLAGS instead. Note that these flags are passed both to the compiler and
to the linker. For example, in order to build a 32-bit binary on an x86_64
Linux system with SSL support without support for compression but when OpenSSL
requires ZLIB anyway :
네이티브 컴파일러의 대상과 일치하지 않는 특정 대상 바이너리를 빌드할 수 있습니다.
이것은 32비트 바이너리를 빌드하려는 64비트 시스템에서 특히 그렇습니다.
이를 위해 ARCH 변수를 사용하십시오.
지금은 몇 가지 x86 변종(i386,i486,i586,i686,x86_64), 두 가지 일반 변종(32,64)에 대해서만
알고 있으며, 그에 따라 -m32/-m64 및 -march=를 설정합니다.
이 변수는 ARCH_FLAGS를 사전 설정 값으로 설정하는 데만 사용되므로 시스템에 필요한
아치별 플래그를 알고 있는 경우 대신 ARCH_FLAGS를 설정하는 것이 좋습니다.
이러한 플래그는 컴파일러와 링커 모두에 전달됩니다. 예를 들어 압축 지원 없이 SSL을
지원하는 x86_64 Linux 시스템에서 32비트 바이너리를 빌드하려면 OpenSSL에 ZLIB가 필요합니다.
$ make TARGET=linux-glibc ARCH=i386 USE_OPENSSL=1 ADDLIB=-lz
Recent systems can resolve IPv6 host names using getaddrinfo(). This primitive
is not present in all libcs and does not work in all of them either. Support in
glibc was broken before 2.3. Some embedded libs may not properly work either,
thus, support is disabled by default, meaning that some host names which only
resolve as IPv6 addresses will not resolve and configs might emit an error
during parsing. If you know that your OS libc has reliable support for
getaddrinfo(), you can add USE_GETADDRINFO=1 on the make command line to enable
it. This is the recommended option for most Linux distro packagers since it's
working fine on all recent mainstream distros. It is automatically enabled on
Solaris 8 and above, as it's known to work.
최신 시스템은 getaddrinfo()를 사용하여 IPv6 호스트 이름을 확인할 수 있습니다.
이 프리미티브는 모든 libcs에 존재하지 않으며 모든 libcs에서도 작동하지 않습니다.
glibc의 지원은 2.3 이전에 중단되었습니다.
일부 내장 라이브러리도 제대로 작동하지 않을 수 있으므로 기본적으로 지원이
비활성화되어 있습니다. 즉, IPv6 주소로만 확인되는 일부 호스트 이름은 확인되지 않고
구성은 구문 분석 중에 오류를 생성할 수 있습니다.
OS libc가 getaddrinfo()를 안정적으로 지원한다는 것을 알고 있다면 make 명령줄에
USE_GETADDRINFO=1을 추가하여 활성화할 수 있습니다.
이것은 최근의 모든 주류 배포판에서 잘 작동하기 때문에 대부분의 Linux 배포판 패키지
도구에 권장되는 옵션입니다.
작동하는 것으로 알려진 Solaris 8 이상에서는 자동으로 활성화됩니다.
If your system supports PCRE (Perl Compatible Regular Expressions), then you
really should build with libpcre which is between 2 and 10 times faster than
other libc implementations. Regex are used for header processing (deletion,
rewriting, allow, deny). Please see section 4 about dependencies to figure
how to build with PCRE support.
시스템이 PCRE(Perl Compatible Regular Expressions)를 지원하는 경우 다른 libc
구현보다 2~10배 빠른 libpcre로 빌드해야 합니다.
Regex는 헤더 처리(삭제, 재작성, 허용, 거부)에 사용됩니다.
PCRE 지원으로 빌드하는 방법을 알아보려면 종속성에 대한 섹션 4를 참조하세요.
It is possible to add native support for SSL, by passing "USE_OPENSSL=1" on the
make command line. The libssl and libcrypto will automatically be linked with
HAProxy. Some systems also require libz, so if the build fails due to missing
symbols such as deflateInit(), then try again with "ADDLIB=-lz". Please check
section 4 about dependencies for more information on how to build with OpenSSL.
make 명령줄에서 "USE_OPENSSL=1"을 전달하여 SSL에 대한 기본 지원을 추가할 수 있습니다.
libssl 및 libcrypto는 자동으로 HAProxy와 연결됩니다.
일부 시스템은 libz도 필요로 하므로 deflateInit()와 같은 누락된 기호로 인해 빌드가
실패하면 "ADDLIB=-lz"로 다시 시도하십시오.
OpenSSL로 빌드하는 방법에 대한 자세한 내용은 종속성에 대한 섹션 4를 확인하세요.
HAProxy can compress HTTP responses to save bandwidth. Please see section 4
about dependencies to see the available libraries and associated options.
HAProxy는 HTTP 응답을 압축하여 대역폭을 절약할 수 있습니다.
사용 가능한 라이브러리 및 관련 옵션을 보려면 종속성에 대한 섹션 4를 참조하세요.
By default, the DEBUG_CFLAGS variable is set to '-g' to enable debug symbols.
It is not wise to disable it on uncommon systems, because it's often the only
way to get a usable core when you need one. Otherwise, you can set DEBUG to
'-s' to strip the binary.
기본적으로 DEBUG_CFLAGS 변수는 디버그 기호를 활성화하기 위해 '-g'로 설정됩니다.
일반적이지 않은 시스템에서는 비활성화하는 것이 현명하지 않습니다.
필요할 때 사용 가능한 코어를 얻을 수 있는 유일한 방법이기 때문입니다.
그렇지 않으면 DEBUG를 '-s'로 설정하여 바이너리를 제거할 수 있습니다.
If the ERR variable is set to any non-empty value, then -Werror will be added
to the compiler so that any build warning will trigger an error. This is the
recommended way to build when developing, and it is expected that contributed
patches were tested with ERR=1.
ERR 변수가 비어 있지 않은 값으로 설정되면 -Werror가 컴파일러에 추가되어 빌드 경고가
오류를 트리거합니다. 이것은 개발할 때 권장되는 빌드 방법이며 기여한 패치는 ERR=1로
테스트되었을 것으로 예상됩니다.
The DEBUG variable is used to extend the CFLAGS and is preset to a list of
build-time options that are known for providing significant reliability
improvements and a barely perceptible performance cost. Unless instructed to do
so by some project developers, or trying to save the last ounce of performance,
these options should not be changed. Among the usable ones are:
DEBUG 변수는 CFLAGS를 확장하는 데 사용되며 상당한 안정성 향상과 거의 감지할 수
없는 성능 비용을 제공하는 것으로 알려진 빌드 시간 옵션 목록으로 사전 설정됩니다.
일부 프로젝트 개발자가 그렇게 하도록 지시하지 않았거나 마지막 온스의 성능을 저장하려는
경우가 아니면 이러한 옵션을 변경해서는 안 됩니다.
사용할 수 있는 것은 다음과 같습니다.
- -DDEBUG_STRICT: enable some runtime assertions at key places in the code.
The goal is to emit a warning or stop the program if certain expected
conditions are not met, and whose violation will result in a misbehaving
process due to memory corruption or other significant trouble, possibly
caused by an attempt to exploit a bug in the program or a library it relies
on. The option knows 3 values: 0 (disable all such assertions, the default
when the option is not set), 1 (enable all inexpensive assertions), and
2 (enable all assertions even in fast paths). Setting the option with no
value corresponds to 1, which is the recommended value for production.
- -DDEBUG_STRICT: 코드의 주요 위치에서 일부 런타임 어설션을 활성화합니다.
목표는 특정 예상 조건이 충족되지 않은 경우 경고를 표시하거나 프로그램을
중지하는 것입니다. 이 조건을 위반하면 프로그램의 버그를 악용하려는 시도로
인해 발생할 수 있는 메모리 손상 또는 기타 심각한 문제로 인해 프로세스가
오작동하게 됩니다. 의존하는 라이브러리입니다.
이 옵션은 0(모든 어설션 비활성화, 옵션이 설정되지 않은 경우 기본값),
1(저렴한 모든 어설션 활성화), 2(빠른 경로에서도 모든 어설션 활성화)의 3가지
값을 알고 있습니다. 값 없이 옵션을 설정하면 프로덕션 권장 값인 1에 해당합니다.
- -DDEBUG_STRICT_ACTION: indicates how to react to a check violation. There
are 3 types of checks: BUG (condition that is known to have serious
consequences), WARN (warning about a highly suspicious condition which the
process may recover from, but whose unknown cause may also have serious
consequences), CHECK (verification whether a condition that developers now
consider impossible still happens). The variable takes a value from 0 to 3,
that adjusts the behavior on these 3 violations:
- -DDEBUG_STRICT_ACTION: 검사 위반에 대응하는 방법을 나타냅니다.
검사에는 3가지 유형이 있습니다. BUG(심각한 결과를 초래하는 것으로 알려진 상태),
WARN(프로세스가 복구될 수 있지만 원인을 알 수 없는 경우 심각한 결과를 초래할 수
있는 매우 의심스러운 상태에 대한 경고), CHECK(확인 개발자가 지금 불가능하다고
생각하는 조건이 여전히 발생합니다).
이 변수는 다음 3가지 위반에 대한 동작을 조정하는 0에서 3 사이의 값을 취합니다.
BUG WARN CHECK
0 warn warn warn
1 stop warn warn
2 stop stop warn
3 stop stop stop
The default value is 1, which is the best balance for production in that it
will do its best to prevent a known bogus process from running away, but
will let it run if it believes it can recover. Users running the process in
sensitive environments (finance etc) may prefer to run at level 2 to make
sure to stop any detected anomaly before it may have an impact. Level 3
should only be used at the request of developers. In any case, any emitted
warning should be reported to developers.
기본값은 1이며, 알려진 가짜 프로세스가 실행되는 것을 방지하기 위해 최선을
다하지만 복구할 수 있다고 판단되면 실행을 허용한다는 점에서 프로덕션에 가장
적합한 균형입니다.
민감한 환경(금융 등)에서 프로세스를 실행하는 사용자는 감지된 이상 현상이 영향을
미치기 전에 중지하도록 레벨 2에서 실행하는 것을 선호할 수 있습니다.
레벨 3은 개발자의 요청이 있는 경우에만 사용해야 합니다. 어떤 경우든 방출된 경고는
개발자에게 보고해야 합니다.
- -DDEBUG_MEMORY_POOLS: this enables by default extra controls around memory
allocation that will help detect coding errors such as double-frees and
freeing a bad memory location. It will also detect earlier risks of memory
overflows, which may have security implications. The cost is extremely low
(less than 1% increase in memory footprint). This is equivalent to adding
"-dMtag" on the command line. This option is enabled in the default build
options.
- -DDEBUG_MEMORY_POOLS: 기본적으로 메모리 할당에 대한 추가 제어를 활성화하여
이중 해제 및 잘못된 메모리 위치 해제와 같은 코딩 오류를 감지하는 데 도움이 됩니다.
또한 보안에 영향을 줄 수 있는 메모리 오버플로의 초기 위험을 감지합니다.
비용이 매우 저렴합니다(메모리 공간이 1% 미만 증가).
이는 명령줄에 "-dMtag"를 추가하는 것과 같습니다.
이 옵션은 기본 빌드 옵션에서 활성화됩니다.
- -DDEBUG_DONT_SHARE_POOLS: this will keep separate pools for same-sized
objects of different types. Using this increases the memory usage a little
bit but further reduces the risk of memory management related bugs and will
lead to more accurate traces in case of error. It is equivalent to adding
"-dMno-merge" on the command line. It is not enabled in the default build
options.
- -DDEBUG_DONT_SHARE_POOLS: 다른 유형의 동일한 크기 개체에 대해 별도의 풀을
유지합니다. 이를 사용하면 메모리 사용량이 약간 증가하지만 메모리 관리 관련 버그의
위험이 더욱 줄어들고 오류 발생 시 더 정확한 추적으로 이어집니다.
명령줄에 "-dMno-merge"를 추가하는 것과 같습니다. 기본 빌드 옵션에서는 활성화되어
있지 않습니다.
- -DDEBUG_POOL_INTEGRITY: this will enable runtime detection and stopping of
a class of bugs known as "use after free", which consists in modifying a
memory area after freeing it while it was reused for something else. This
option is quite powerful but such bugs are fortunately extremely rare, and
it will cause a measurable performance degradation (a few percent). This is
equivalent to adding "-dMcold-first,integrity" on the command line. This
option is not enabled by default but users running development versions on
moderate performance sites in order to participate to reliability testing
are encouraged to use it, in combination with -DDEBUG_DONT_SHARE_POOLS and
-DDEBUG_MEMORY_POOLS, as this could catch dangerous regressions.
- -DDEBUG_POOL_INTEGRITY: 이것은 "해제 후 사용(use after free)"으로 알려진 버그
클래스의 런타임 감지 및 중지를 활성화합니다. 이는 다른 용도로 재사용되는 동안 메모리
영역을 해제한 후 수정하는 것으로 구성됩니다.
이 옵션은 매우 강력하지만 다행히도 이러한 버그는 극히 드물며 측정 가능한 성능
저하(몇 퍼센트)가 발생합니다.
이는 명령줄에 "-dMcold-first,integrity"를 추가하는 것과 같습니다.
이 옵션은 기본적으로 활성화되어 있지 않지만 안정성 테스트에 참여하기 위해 중간 성능
사이트에서 개발 버전을 실행하는 사용자는 위험한 회귀를 잡을 수 있으므로
-DDEBUG_DONT_SHARE_POOLS 및 -DDEBUG_MEMORY_POOLS와 함께 사용하는 것이 좋습니다.
https://cpuu.postype.com/post/9617696 [Use-After-Free Attacks 개요]
As such, for regular production, "-DDEBUG_STRICT -DDEBUG_MEMORY_POOLS" is
recommended. For security sensitive environments, it is recommended to use
"-DDEBUG_STRICT -DDEBUG_STRICT_ACTION=2 -DDEBUG_MEMORY_POOLS \
-DDEBUG_DONT_SHARE_POOLS". For deployments dedicated to testing new versions or
when trying to nail a bug down, use "-DDEBUG_STRICT=2 -DDEBUG_STRICT_ACTION=2 \
-DDEBUG_MEMORY_POOLS -DDEBUG_DONT_SHARE_POOLS -DDEBUG_POOL_INTEGRITY".
The DEP variable is automatically set to the list of include files and also
designates a file that contains the last build options used. It is used during
the build process to compute dependencies and decide whether or not to rebuild
everything (we do rebuild everything when .h files are touched or when build
options change). Sometimes when performing fast build iterations on inline
functions it may be desirable to avoid a full rebuild. Forcing this variable
to be empty will be sufficient to achieve this. This variable must never be
forced to produce final binaries, and must not be used during bisect sessions,
as it will often lead to the wrong commit.
If you need to pass other defines, includes, libraries, etc... then please
check the Makefile to see which ones will be available in your case, and
use/override the USE_* variables from the Makefile.
AIX 5.3 is known to work with the generic target. However, for the binary to
also run on 5.2 or earlier, you need to build with DEFINE="-D_MSGQSUPPORT",
otherwise __fd_select() will be used while not being present in the libc, but
this is easily addressed using the "aix52" target. If you get build errors
because of strange symbols or section mismatches, simply remove -g from
DEBUG_CFLAGS.
Building on AIX 7.2 works fine using the "aix72-gcc" TARGET. It adds two
special CFLAGS to prevent the loading of AIX's xmem.h and var.h. This is done
by defining the corresponding include-guards _H_XMEM and _H_VAR. Without
excluding those header-files the build fails because of redefinition errors.
Furthermore, the atomic library is added to the LDFLAGS to allow for
multithreading via USE_THREAD.
You can easily define your own target with the GNU Makefile. Unknown targets
are processed with no default option except USE_POLL=default. So you can very
well use that property to define your own set of options. USE_POLL and USE_SLZ
can even be disabled by setting them to an empty string. For example :
$ gmake TARGET=tiny USE_POLL="" USE_SLZ="" TARGET_CFLAGS=-fomit-frame-pointer
If you need to pass some defines to the preprocessor or compiler, you may pass
them all in the DEFINE variable. Example:
$ make TARGET=generic DEFINE="-DDEBUG_DONT_SHARE_POOLS -DDEBUG_MEMORY_POOLS"
The ADDINC variable may be used to add some extra include paths; this is
sometimes needed when cross-compiling. Similarly the ADDLIB variable may be
used to specifify extra paths to library files. Example :
$ make TARGET=generic ADDINC=-I/opt/cross/include ADDLIB=-L/opt/cross/lib64
6) How to install HAProxy
=========================
To install haproxy, you can either copy the single resulting binary to the
place you want, or run :
$ sudo make install
If you're packaging it for another system, you can specify its root directory
in the usual DESTDIR variable.
-- end