Hey It’s SPOON!🥄

kubernetes 개념 및 cluster 설치 방법 (2)

2022-06-05T00:00:00+00:00

kubernetes 개념 및 cluster 설치 방법 (2) - kubernetes cluster 설치

1. kubernetes 개념 및 cluster 설치 방법 (1) - kubernetes 개념 정리

2. kubernetes 개념 및 cluster 설치 방법 (2) - kubernetes 개념 정리

Cluster 구조

hostname	ip	역할
k8s-master1	10.1.1.1	마스터 노드
k8s-master2	10.1.1.2	마스터 노드
k8s-worker1	10.1.1.3	워커 노드
k8s-worker2	10.1.1.4	워커 노드
k8s-worker3	10.1.1.5	워커 노드
gitlab	10.1.1.6	pv 저장소

hosts 등록

# vim /etc/hosts
1.1.1 k8s-master1
1.1.2 k8s-master2
1.1.3 k8s-worker1
1.1.4 k8s-worker2
1.1.5 k8s-worker3
1.1.6 gitlab

서버 시간 동기화

# dnf install chronyd
# vim /etc/chronyd.conf

# /etc/chronyd.conf
server time.bora.net iburst
allow 10.1.1.0/24

# /etc/chronyd.conf
server k8s-master1 iburst
server k8s-master2 iburst

방화벽 설정

# systemctl stop firewalld
# systemctl disable firewalld

쿠버네티스는 기본적으로 iptables를 기본 방화벽 정책으로 사용하기 때문에, firewall은 내려주도록 한다.

# dnf install iptables-services
# vim /etc/sysconfig/iptables

# /etc/sysconfig/iptables

#### KUBERNETES API 서버
-I INPUT -p tcp --dport 6443 -j ACCEPT

#### ETCD SERVER 클라이언트 API
-I INPUT -p tcp --dport 2379:2380 -j ACCEPT

#### KUBELET API
-I INPUT -p tcp --dport 10250 -j ACCEPT

#### KUBE-SCHEDULER
-I INPUT -p tcp --dport 10259 -j ACCEPT

#### KUBE-CONTROLLER-MANAGER
-I INPUT -p tcp --dport 10257 -j ACCEPT

#### KUBELET API
-I INPUT -p tcp --dport 10250 -j ACCEPT

#### NODEPORT SERVICE
-I INPUT -p tcp -m tcp --dport 30000:32767 -j ACCEPT

쿠버네티스 사용 모듈 로드

# cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
EOF

# cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF

sysctl --system

iptables가 브릿지 드라이브를 사용하여 통신하는 패킷을 filtering 할 수 있도록 하기 위해 br_netfilter 모듈을 적재한다.

이 모듈을 iptables가 사용 할 수 있도록 net.bridge.bridge-nf-call-iptables도 함께 적재한다.

환경 변수 설정

# vim /etc/profile

# /etc/profile
export KUBE_VERSION='1.23' # kubernetes version

컨테이너 런타임 다운로드

# curl -L -o \
/etc/yum.repos.d/devel:kubic:libcontainers:stable.repo \
[https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_8/devel:kubic:libcontainers:stable.repo](https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/CentOS_8/devel:kubic:libcontainers:stable.repo)
# curl -L -o \
/etc/yum.repos.d/devel:kubic:libcontainers:stable:cri-o:${KUBE_VERSION}.repo [https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:${KUBE_VERSION}/CentOS_8/devel:kubic:libcontainers:stable:cri-o:${KUBE_VERSION}.repo](https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$%7BVERSION%7D/CentOS_8/devel:kubic:libcontainers:stable:cri-o:$%7BVERSION%7D.repo)

# dnf install cri-o cri-tools

# systemctl daemon-reload
# systemctl enable crio --now

kubernetes 다운로드

# cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg [https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg](https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg)
exclude=kubelet kubeadm kubectl
EOF

# dnf install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
# systemctl enable --now kubelet

NFS 구축

# dnf install -y nfs-utils
# systemctl start nfs-server
# systemctl enable nfs-server
# systemctl start rpcbind
# systemctl enable rpcbind
# mkdir /kube_store
# vim /etc/exports

# /etc/exports
/kube_store 10.1.1.0/24(rw,sync,no_root_squash)

# dnf install -y nfs-utils
# mkdir /kube_store
# showmount -e gitlab
# mount -t nfs gitlab:/kube_store /kube_store
# vim /etc/fstab

# /etc/fstab
gitlab:/kube_store /kube_store nfs sync 0 0

kubernetes 설치

# vim /kube_store/kubeadm-config.yml

# /kube_store/kubeadm-config.yml
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
localAPIEndpoint:
  bindPort: 6443
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.23.0
controlPlaneEndpoint: "k8s-master1:6334"
apiServer:
  extraArgs:
    authorization-mode: "Node,RBAC"
networking:
  podSubnet: "192.168.0.0/16"
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: JoinControlPlane
localAPIEndpoint:
  bindPort: 6443
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd

# kubeadm init --config kubeadm-config.yml --upload-certs

CNI 다운로드

# curl https://docs.projectcalico.org/manifests/calico.yaml -O --insecure
# kubectl apply -f clico.yaml

# vim /etc/sysconfig/iptables

# /etc/sysconfig/iptables

-I INPUT -p tcp --dport 179 -j ACCEPT
-I INPUT -p udp --dport 4789 -j ACCEPT
-I INPUT -p tcp --dport 5473 -j ACCEPT
-I INPUT -p tcp --dport 443 -j ACCEPT

# systemctl restart iptables

kubernetes cluster 구축

# kubeadm join k8s-master1:6334 \
--token aaly0a.sp3dz8w4z8pe5dbb \
--discovery-token-ca-cert-hash sha256:a848eba0c188c12ab66aeb2359dee021f778ebd350f7c0c538949c7d1a57c320 \
--control-plane \
--certificate-key cc191962adc302a7127ad2ff830cacba816afb610018c70b4b7efcdff060764e \
--apiserver-bind-port 6334

# kubeadm join k8s-master1:6334 \
--token aaly0a.sp3dz8w4z8pe5dbb \
--discovery-token-ca-cert-hash sha256:a848eba0c188c12ab66aeb2359dee021f778ebd350f7c0c538949c7d1a57c320

Storage Class

# cd /kube_store
# git clone https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner.git
# cd nfs-subdir-external-provisioner/deploy
# kubectl apply -f rbac.yaml
# vim deployment.yaml

# /kube_store/nfs-subdir-external-provisioner/deploy/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: kube-system
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nfs-client-provisioner
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: k8s.gcr.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: k8s-sigs.io/nfs-subdir-external-provisioner
            - name: NFS_SERVER
              value: 10.1.1.6
            - name: NFS_PATH
              value: /kube_store
      volumes:
        - name: nfs-client-root
          nfs:
            server: 10.1.1.6
            path: /kube_store

# kubectl apply -f deployment.yaml
# kubectl apply -f class.yaml

마치며

여기까지 마쳤다면 성공적으로 쿠버네티스 클러스터를 구축 할 수 있습니다. 이전 포스팅에서 개념을 이해하셨다면 그렇게 어렵지 않게 구축하셨을거라 생각합니다. 하지만 현재 상태로는 쿠버네티스간의 failover가 정상적으로 작동하지 않게 됩니다. 해당 이유는 다음 포스팅에서 설명하도록 하고 이번 포스팅은 이만 마치도록 하겠습니다.

kubernetes 개념 및 cluster 설치 방법 (1)

2022-05-25T00:00:00+00:00

kubernetes 개념 및 cluster 설치 방법 (1) - kubernetes 개념 정리

1. kubernetes 개념 및 cluster 설치 방법 (1) - kubernetes 개념 정리

개요

오랜만에 글을 작성합니다. 그 동안 놀았던 것은 아니고 여러 일이 겹치는 바람에 포스팅을 하지 못했습니다. 최근 회사는 kvm, hyper-v, openstack 등 가상화 관련한 프로젝트를 시작했습니다. 이번 포스팅에서는 가상화 중에서도 컨테이너 기반 가상화와 관련된 쿠버네티스에 대해 다뤄볼까 합니다. 사실 쿠버네티스보다 다른 가상화 스터디를 먼저 시작하였지만, AWX 공부를 시작하면서 쿠버네티스를 가장 먼저 구축하게 되었기 때문에 쿠버네티스 포스팅을 가장 먼저 시작하게 되었습니다. 이번 포스팅에서는 쿠버네티스와 관련 된 개념을 먼저 살펴보고, 다음 포스팅에서 본격적으로 쿠버네티스 클러스터를 구축 해 보겠습니다.

컨테이너란?

쿠버네티스를 다루면서 소프트웨어 서비스를 실행하는 데 필요한 특정 버전의 프로그래밍 언어 런타임 및 라이브러리와 같은 종속 항목과 애플리케이션 코드를 함께 포함하는 경량 패키지.

서비스에 필요한 관련 패키지, 데몬을 한데 묶어서 작은 서버를 구축 후 배포하는 개념.

호스트 OS의 리소스를 논리적으로 분리하고, 여러 개의 컨테이너가 공유해서 사용한다. VM과 달리 운영체제 커널을 공유하므로 훨씬 빠르고 메모리도 적게 사용한다.

kubernetes란?

: 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템. 컨테이너 오케스트레이션 기능을 지원한다. 노드 클러스터링, 로드 밸런싱, 배포 및 복제 자동화, 장애 복구 기능, 오토스케일링, 스케줄링, 로깅 및 모니터링 등을 지원한다.

도커와 쿠버네티스 차이?

도커 : 도커는 컨테이너 기반의 오픈소스 플랫폼. 즉 컨테이너 실행에 필요한 파일과 설정값인 이미지를 컨테이너에 띄우고 실행 할 수 있는 기술. 한개의 서버에 컨테이너를 관리한다면 Docker가 적합.
쿠버네티스 : 쿠버네티스는 컨테이너를 쉽고 빠르게 배포/확장하고 관리를 자동화해주는 오픈소스 플랫폼. 컨테이너 시장이 커지고 점점 더 많은 컨테이너를 관리, 배포해야 상황에서 사용하기 좋음.

cgroup이란?¹

: 단일, 또는 태스크 단위의 프로세스 그룹에 대한 자원 할당을 제어하는 커널 모듈. 컨테이너에서는 컨테이너가 생성되면 컨테이너의 프로세스들을 담당하는 컨테이너 cgroup이 생성된다. 컨테이너 내부 프로세스가 fork system call을 통해서 자식 프로세스들을 생성해도 생성된 자식 프로세스 역시 컨테이너 cgroup에 소속되기 때문에 컨테이너의 리소스를 제어하기 위해서는 컨테이너 cgroup을 제어하면 된다.

cgroup을 제어하는 방법에는 cgroupfs와 systemd에서 제공하는 API를 사용하는 방법이 있다.

cgroupfs : cgroup 제어를 위해 탄생한 특수 file system. cgroup 정보는 리눅스 커널 내부에서 관리하고 있으며 리눅스 커널은 cgroup 제어를 위해 별도의 system call을 제공하지 않고 cgroupfs를 제공하고 있다. cgroupfs를 사용하여 cgroup을 관리하는 방법은 cgroupfs에 디렉토리를 생성하면 된다. 경로는 /sys/fs/cgroup/memory.
systemd : 리눅스의 init process이며 기존 기능은 데몬 프로세스 제어이지만 cgroup을 제어하는 역할도 수행한다. systemd의 cgroup 제어 기능은 자신이 제어하는 데몬 프로세스의 리소스 사용량을 제어하기 위해 사용된다. systemd-run 명령어를 통해 unit을 생성하고 실행하면 cgroup이 생성된다.

결국 cgroup을 제어하기 위해 두 가지 방식이 사용되는데, 두 가지 방식의 차이점은 요청하는 주체가 다른 것일 뿐 동일한 동작을 한다. cgroupfs 드라이버 방식을 사용 시 쿠버네티스가 직접 cgroup 디렉토리에 관여를 하고, systemd 드라이버 방식을 사용 시 systemd API를 통해 cgroup 디렉토리에 관여를 하기 때문에 두 방식의 cgroup 생성 경로가 달라지게 된다.

systemd는 사용자 레벨의 어플리케이션이고 cgroupfs는 직접 cgroup을 관리하는 방식이기 때문에 안정성 차이는 있을 수 있으나 성능상의 차이점은 없다. 다만 kubernetes 공식 문서에는 kubelet 및 도커와 다른 프로세스가 서로 다른 cgroup 제어 정책을 사용하게 되면 리소스가 부족할 때 불안정해지는 사례가 있었다고 보고되었다.

컨테이너 런타임이란?

: 컨테이너 실행을 담당하는 소프트웨어. 대표적으로 dockershim, containerd, CRI-O 등이 있다.

docker-shim : 도커 호환성을 위해 쿠버네티스에서 자체적으로 개발 한 도커 컨테이너 런타임 툴 경로 : /var/run/dockershim.sock
containerd : 도커 사에서 개발한 컨테이너 런타임 프로젝트. 경로 : /run/containerd/containerd.sock
CRI-O : 레드햇이 개발한 쿠버네티스를 위한 표준 컨테이너 런타임. 기본적인 cgroup 관리 모듈로 systemd를 사용한다. 경로 : /var/run/crio/crio.sock

CRI란?

: CRI가 생기기 전에는 대표적인 컨테이너 런타임 툴인 도커와 rkt가 kubelet에 직접 통합되어있었으나, 이 외에도 새로운 컨테이너 런타임 툴이 생겨나면서 쿠버네티스에서 다양한 런타임 툴을 지원하기 위해 런타임간의 인터페이스를 통일화 할 수 있게 해주는 CRI를 개발하였다.

따라서 모든 컨테이너 런타임 툴은 CRI 스펙에 맞춰 컴포넌트를 구현하면 kubelet과 호환 할 수 있다.

쿠버네티스에서 도커 런타임 지원을 중단 한 이유?²

: 컨테이너 런타임과 호환성이 없기 때문에. Docker는 기본적으로 쿠버네티스에 통합되도록 설계되어있지 않기 때문에 호환성에 많은 문제가 있다.

도커가 먼저 개발되었기 때문에 도커는 쿠버네티스의 CRI기준에 맞지 않아 쿠버네티스에서 도커를 지원하기 위한 도커 런타임인 docker-shim을 개발하게 됨.

그러나 쿠버네티스에서 docker-shim 유지보수에 어려움을 느꼈고, docker에서는 CRI 기준에 맞춘 런타임 툴을 따로 개발하지 않아 지원을 중단하게 되었다.

이 외에도 docker의 모든 명령은 root 권한을 이용해야하기 때문에 보안상의 문제도 있고, 데몬 형태로 실행되는 도커는 이미지 빌드, 관리, 공유, 실행 등 도커 자체에도 많은 기능이 있고 데몬 하위에 모든 컨테이너를 자식 프로세스로 소유하고 있어 쿠버네티스 상에서 필요하지 않은 기능으로 인해 쿠버네티스가 무거워지고, 도커 데몬이 중지되면 쿠버네티스 상에서도 영향이 미치기 때문에 도커의 런타임 지원을 중단하였다.

어떤 컨테이너 런타임을 선택해야 할까?³

쿠버네티스 용어

kubeadm : 쿠버네티스에서 제공하는 기본적인 도구, 쿠버네티스 클러스트 구축 관련 명령어.
kubelet : 클러스터 내의 모든 노드에서 실행되는 에이전트. pod 내의 컨테이너들이 실행되는 것을 직접적으로 관리 및 상태 체크. 또한 master node와 worker node 간 통신을 책임진다.
kubectl : 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구.

쿠버네티스 아키텍처

쿠버네티스 클러스터 아키텍처

ETCD : 노드 정보 등 쿠버네티스 클러스터 데이터를 저장하는 고가용성 키-값 저장소, etcd 데이터 백업 계획은 필수이다.
kube-apiserver : 쿠버네티스 API, 외/내부에서 관리자의 원격 명령을 받을 수 있는 컴포넌트 쿠버네티스의 frontend. 작업 상태를 정의하고 조회 할 수 있는 RESTful 웹 서비스를 제공한다. 쿠버네티스의 각 구성 요소는 API 서버를 거쳐서 서로 통신하게 된다.

kube-controller-manager : 쿠버네티스는 현재 시스템을 사용자가 정의한 상태로 맞춰준다. 오브젝트의 현재 상태를 지속적으로 체크하고 상태를 제어한다. 컨트롤러 프로세스를 실행하고 클러스터의 실제 상태를 원하는 사양으로 조정한다.

 - Node Controller : 노드가 다운되었을 때 알림과 대응에 관한 역할을 한다.

 - Replication Controller : 지정 된 수의 pod들을 유지시켜 주는 역할을 한다.

 - Endpoints Controller : 서비스와 pod를 연결시켜 endpoint 오브젝트를 만든다.

 - Service Account & Token Controllers : 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다.

kube-scheduler : 생성 된 pod를 노드에 할당 해 주는 컴포넌트. 리소스, 하드웨어, 소프트웨어, 정책, 워크로드 등을 참고하여 가장 최적화 된 노드에 pod를 배치한다.
kube-proxy : 네트워크 연결을 관리하고 노드간에 네트워크 규칙을 유지한다.

네트워크 플러그인

싱글 노드에서 Pod to Pod 통신 시 쿠버네티스에서 기본으로 제공하는 kubenet을 통해 간단한 네트워크 플러그인을 제공해준다. 하지만 이 네트워크 플러그인은 크로스 노드 네트워킹이나 네트워크 정책 설정과 같은 고급 기능은 구현되어있지 않다. 따라서 CNI(Container Network Interface)의 스펙을 준수하는 네트워크 플러그인을 따로 사용해야한다.

기존 네트워크 구조로 여러 노드를 구성하게 되면 각 노드에 중복되는 ip가 할당되기 때문에 요청이 왔을 때 어느 노드의 파드로 패킷이 전달되어야 하는지 알 수 없다.

따라서 쿠버네티스 네트워크에 오버레이 네트워크를 구성해주고 파드와 호스트 인터페이스를 연결해주는 부분을 별도의 모듈로 분리한 CNI가 필요하다.

CNI는 커널 라우팅, 동적 라우팅, Pod 인터페이스 생성, IP / Subnet / Routing Table 설정, Proxy ARP 기능 등을 수행한다.

Application 배포 방법

Replicaset : pod의 복제본을 관리하는 컨트롤러.

Deployment : stateless 앱을 배포할 때 사용되는 가장 기본이 되는 컨트롤러. deployment는 replicaset을 관리하게 되는데 배포를 위한 기능을 제공한다. 롤링업데이트, 배포 중단, 롤백 등이 가능하다. deployment controller는 지속적으로 배포 된 인스턴스들을 모니터링하고, 노드가 다운되거나 삭제되면 해당 컨트롤러가 클러스터 내부의 다른 노드 인스턴스로 교체해준다.

쿠버네티스 서비스 종류

ClusterIP : 클러스터 내부에서 해당 ClusterIP를 통해 Pod to Pod 통신을 가능하게 한다. ClusterIP는 서비스 (Deployment / Replicaset ) 단위로 생성되므로, ClusterIP 주소로 서비스를 호출하면 backend 단의 Pod 중 하나로 프록시된다.

NodePort : 클러스터에 속한 Node의 IP:NodePort를 Pod의 Service Port와 매핑시킨다.

LoadBalancer : 외부의 LB를 생성하여, 외부 LB에서 NodePort로 들어오는 트래픽을 프록시한다.

번외) Ingress : 서비스의 종류는 아니지만, 외부에서 클러스터 내부로 들어오는 네트워크 요청을 처리 할 방법을 정의한다.

쿠버네티스 스토리지

pv : 인프라 관리자가 사전에 정의 해 놓은 볼륨
pvc : 사용자 ( 개발자 ) 가 pod를 생성하기 위해 요청하는 볼륨
Storage Class : 매번 pvc를 요청 할 때 마다 pv 를 생성할 수가 없기 때문에, 맞는 pv가 없을 시 자동으로 pv를 생성할 수 있도록 미리 pv를 생성 할 공간을 선언.

마치며

이번 포스팅에서는 쿠버네티스 관련 개념 및 용어에 대해 정리해보았다. 개념도 어렵고 고려해야 할 사항이 많아 구축하기가 까다롭긴 하지만 잘 사용한다면 충분히 매력적인 클라우드 컴퓨팅을 구성 할 수 있을 것 같다. 다음 포스팅에서는 본격적으로 쿠버네티스 클러스터 구축에 대해서 다룰 예정이다.

참고 : https://tech.kakao.com/2020/06/29/cgroup-driver/ ↩
참고 : https://ikcoo.tistory.com/189 ↩
관련 논문 참조 : https://www.scitepress.org/Papers/2020/93404/93404.pdf ↩

오픈소스 방화벽 pfSense 설치하기 (2)

2022-03-20T00:00:00+00:00

오픈소스 방화벽 pfSense 설치하기 (2) - 포트포워딩 및 HAproxy 설정

1. 오픈소스 방화벽 pfSense 설치하기 (1) - pfSense 설치

2. 오픈소스 방화벽 pfSense 설치하기 (2) - 포트포워딩 및 HAproxy 설정

포트포워딩

지난시간 pfSense 설치에 이어 이번 포스팅에서는 pfSense 기능을 몇가지 사용해보겠습니다. 먼저 가장 기본적인 포트포워딩 설정부터 진행해보겠습니다.

포트포워딩 설정은 매우 간단합니다. 먼저 LAN 아이피 대역과 동일한 대역의 웹서버 한 대를 세팅해줍니다. 이 때 게이트웨이는 pfSense의 LAN ip로 설정 해주셔야 합니다.

해당 웹서버를 외부에서 접속하기 위해 Destination을 WAN address로 설정하고, port는 원하는 포트로 설정해줍니다. 저는 8010으로 설정해주었습니다. Redirect target IP는 웹서버 사설 ip로 설정해주시고 Redirect target port는 HTTP 포트로 설정합니다. 웹서버 포트를 다른 포트로 설정하신 분들은 Redirect target port를 Other로 설정해주시고 설정하신 포트로 변경 해 주시면 됩니다.

그 후 pfSense의 WAN address에 설정한 포트로 접속하시면 해당 웹서버에 접속 하실 수 있습니다.

주의하실 점은 포트포워딩을 설정하게 되면 자동으로 방화벽 룰이 추가가 되는데, pfSense의 룰은 위에서부터 아래로 순차적으로 적용되므로 포트포워딩의 접속 허용 룰이 block rule보다 아래에 있게 되면 접속이 불가능 할 수 있습니다.

HAproxy

이어서 원활한 웹서버 관리를 위해 HAproxy 설정을 진행해보겠습니다.

HAproxy란 소프트웨어 로드 밸런서로, 네트워크 스위치에서 제공하는 L4, L7 기능 및 로드 밸런서 기능을 제공합니다.

pfSense에서는 간단한 패키지 설치만으로도 HAproxy를 GUI 환경에서 사용하실 수 있습니다.

우선 패키지를 설치하기 위해 System - Package Manager - Available Packages탭으로 들어가 haproxy 패키지를 설치합니다.

개발중인 가장 최신버전은 뒤에 devel이 붙습니다. 취향에 따라 써주시면 됩니다. 저는 안정화 버전을 사용하기 위해 haproxy를 설치하겠습니다.

HAproxy 패키지를 설치하게되면 Services 탭에 HAProxy라는 메뉴가 생긴 것을 확인 할 수 있습니다. 해당 탭의 Setting메뉴를 클릭하면 HAproxy 설정을 할 수 있습니다.

맨 위에 Enable HAProxy 버튼을 눌러 HAproxy를 활성화 시키고 Maxinum connections 값을 설정 해 줍니다. 이 값은 HAproxy를 설정 할 서버의 처리량에 따라 달라지기 때문에 각자 환경에 맞게 세팅해주시면 됩니다.

저는 테스트용으로 사용 할 예정이기 때문에 임의의 숫자를 넣어 테스트를 진행하겠습니다.

그 후 요청을 받아들일 IP를 설정하기 위해 Firewall - Virtual IPs 탭에 들어가 신규 가상 ip를 하나 만들어줍니다.

실질적으로 로드밸런싱 하고싶은 서버 2대를 HAproxy backend로 설정 해 줍니다. 저는 기존에 생성한 웹서버 2대를 로드밸런싱 할 예정인데, 가중치를 9:1로 두어 webserver01를 10번 중 9번정도 요청이 가도록 설정 할 예정입니다.

HAproxy frontend에는 아까 생성했던 가상 ip를 넣고, 방금 만든 HAproxy backend와 연결 해 줍니다. 이제 가상 ip로 요청을 하면 backend에 있는 두 웹서버와 연결이 되어 9:1의 비율로 호출 할 것입니다.

가상 ip 역시 외부에서 호출이 가능해야하므로 꼭 Port Fowarding 설정을 하고 방화벽 rule을 추가해줍시다.

실제로 Port Fowarding ip 접속하여 새로고침을 할 경우 9:1의 비율로 webserver01과 webserver02가 번갈아가면서 나타나는 걸 확인하실 수 있습니다.

마치며

오늘은 간단한 설정으로 pfSense에서 포트포워딩 하는 방법과 소프트웨어 패키지로 로드밸런싱 하는 방법을 알아보았습니다. 설정도 매우 간단하면서 GUI 환경에서 다룰 수 있기 때문에 초보자분들이 사용하기 매우 편리합니다. 또한 많은 회사에서 유용하게 쓰고있는 두 기능이기 때문에 활용도도 높을 것 같습니다.

실제로 저는 private cloud 환경을 구성 할 때 ip가 한정적이기 때문에 vm을 내부 네트워크로 생성하고, 외부 네트워크와 통신 할 수 있게끔 하기 위해 pfSense를 자주 이용합니다.

다음 포스팅에서는 조금 더 다양한 pfSense의 기능을 사용해보도록 하고 이번 포스팅은 여기서 마치겠습니다.

오픈소스 방화벽 pfSense 설치하기 (1)

2022-03-01T00:00:00+00:00

오픈소스 방화벽 pfSense 설치하기 (1) - pfSense 설치

1. 오픈소스 방화벽 pfSense 설치하기 (1) - pfSense 설치

개요

오랜만의 포스팅입니다. 한달 간 많은 일이 있었습니다. 최근 여러 고객사들이 DDoS 공격을 받아 보안 이슈가 회사의 주 된 이슈로 떠올랐습니다. 사내 보안 전문 인력이 없다보니 최소한의 보안 정책으로 일을 하고 있던 저희도, DDoS 공격을 대비하기 위해 바삐 움직여야했습니다. pfSense는 사내 보안 강화 프로젝트의 일환으로 테스트하고 있습니다. 앞으로 포스팅에서 pfSense를 설치해 다양한 기능을 사용 해 볼 예정입니다.

pfSense란?

pfSense는 무료로 사용 할 수 있는 오픈소스 소프트웨어 방화벽입니다. FreeBSD 기반에서 동작하며 매우 가볍습니다. 최근 pfSense의 상용화 버전인 pfSense Plus 버전도 출시되었다고 합니다. 저희는 테스트 용도로 사용 해 볼 예정이니, pfSense CE 버전으로 설치하도록 합시다.

네트워크 구성

pfSense는 우선 외부 네트워크인 WAN과 내부 네트워크인 LAN이 필수적으로 필요합니다. 저는 host pc를 클라우드 컴퓨터로 만든 후, 그 안에 각각 pfsense vm, web서버 vm을 만들어 테스트를 진행하려 합니다. pfsense의 WAN 네트워크는 host pc 네트워크와 동일한 대역 공인 IP를 할당받아 설정하였고, LAN 네트워크는 사설 네트워크를 구성해 각각 web서버와 통신이 가능하도록 구축 할 예정입니다.

pfSens 설치

우선 iso 파일을 다운로드 해 봅시다.

https://www.pfsense.org/download/

위 경로로 들어가 자신에게 맞는 CPU 아키텍처를 선택 후에 ISO 이미지를 다운받아줍니다.

iso 파일을 다운받았으면 각자 해당 iso로 VM, 서버 등등에 설치합니다. 저는 4코어에 8기가 메모리로 생성하였습니다. 주의하실 점은 pfSense는 WAN과 LAN 네트워크를 필요로 하기 때문에 반드시 두 개의 서로 다른 네트워크 디바이스를 추가하여 주셔야 합니다.

그 후 아래 이미지를 따라 설치를 진행해주시면 됩니다. 따로 설명이 필요하지 않은 부분은 넘어가도록 하겠습니다.

VLAN 설정이 필요하신 분들은 위 옵션에서 y를 눌러 VLAN 설정을 진행해주시고, 각각 WAN에 사용 할 인터페이스와 LAN에 사용 할 인터페이스를 설정해줍니다. 저는 현재 인터페이스가 1개만 있기 때문에 WAN 인터페이스만 설정하고 추후 LAN 인터페이스를 추가로 설정 할 예정입니다.

이렇게 모든 pfSense 설치가 끝났습니다.

pfSense 네트워크 설정

이제 pfSense WAN 과 LAN 네트워크를 설정해줍시다. 그 전에 저처럼 네트워크 인터페이스를 1개만 넣어서 생성하신 분들은 네트워크 인터페이스를 한개 더 추가하셔서 2개로 만들어 진행해주시면 됩니다.

먼저 네트워크를 설정 하기 전에 인터페이스를 지정해줍니다. 설치 하실 때 WAN과 LAN 인터페이스를 설정 해 주신 분들은 이 부분은 건너뛰셔도 무방합니다.

1번을 입력하여 네트워크 인터페이스 설정 창으로 들어갑니다.

네트워크 설치 할 때와 동일하게 VLAN 설정 및 WAN, LAN 인터페이스를 지정 해 줍니다. 혹시 WAN, LAN 말고 다른 인터페이스도 추가 해 주고 싶으시면 기타 인터페이스도 설정 해 줍니다. 그 후 설정 완료를 해 주시면 인터페이스가 정상적으로 설정 된 것을 확인 할 수 있습니다.

본격적으로 네트워크 ip를 설정 해 줍니다.

2번을 입력하여 네트워크 ip 설정 창으로 들어갑니다.

먼저 WAN 네트워크 부터 설정 해 줍니다. WAN 네트워크는 host PC와 동일한 공인 IP 대역을 DHCP로 받아 올 예정이기 때문에 DHCP 설정을 yes로 해주고, DHCP6는 사용하지 않을 예정이기 때문에 no로 설정 해 줍니다. 웹 프로토콜은 HTTPS를 쓸 예정이기 때문에 no로 설정 해 줍시다.

LAN 네트워크는 static으로 사설 네트워크를 설정 해 줄 예정이기 때문에 ip를 입력 해 줍니다. 서브넷 마스크와 게이트웨이도 설정 해 준 후 ( 사설 네트워크는 게이트웨이가 필요 없기 때문에 생략 해 줍니다. ) 마찬가지로 웹 프로토콜을 HTTPS로 설정 해 줍니다.

여기까지 설정을 완료 하시면 각각 WAN 및 LAN 네트워크에 ip가 할당 된 것을 확인 하실 수 있습니다.

GUI 페이지 접근 설정

pfSense는 기본적으로 web GUI 페이지를 LAN 네트워크를 통해서만 접속 할 수 있습니다. 언제든지 LAN 네트워크에 접속 할 수 있는 환경이 된다면 굳이 따로 설정하실 필요가 없지만, 관리적인 측면 때문에 공인 네트워크로 접속 할 수 있어야하는 상황이 발생 할 수 있기 때문에 공인 네트워크로도 pfSense 웹 페이지에 접근 할 수 있게 설정 해 봅시다.

8번을 입력하여 커맨드를 입력 할 수 있는 shell로 전환합니다. 그 후 pfctl -d 커맨드를 입력합니다. 해당 커맨드는 pfSense의 방화벽을 disable 하는 설정으로, 일시적으로 모든 방화벽 설정이 비활성화 됩니다. 물론 해당 명령어는 보안에 매우 취약하고 일시적 설정이기 때문에 pfSense에서 설정을 다시 변경할 시에 방화벽이 다시 적용됩니다. web GUI 접근 설정을 하는 동안에는 계속해서 설정이 바뀌어 방화벽이 다시 활성화 되므로, 접속이 안될 때 마다 해당 명령어를 다시 입력 해 주시면 됩니다.

위 명령어를 입력 후 WAN ip 주소로 접속 해 보시면 정상적으로 pfSense GUI 페이지로 들어가는 걸 확인 하실 수 있습니다. pfSense의 초기 비밀번호는 ID : admin / PASSWD : pfsense로 추후 꼭 변경 해 주시길 바랍니다.

이제 web GUI에 접속 할 수 있는 ip를 alias로 묶어서 관리 할 수 있도록 설정 해 봅시다. Firewall > Aliases > IP 탭에서 Add 버튼을 눌러 Management IP를 등록 해 줍니다.

마찬가지로 관리 할 port를 alias로 묶어주도록 합시다. Firewall > Aliases > Ports 탭에서 Add 버튼을 눌러 Managerment Port를 등록합니다. 저는 web에 접근 할 수 있는 80, 443 그리고 외부 네트워크로 CLI 모드도 관리하기 위해 22번 포트를 같이 설정 해 주었습니다.

management ip와 port를 설정 해 주었으니 이제 해당 ip가 해당 port로 접근 할 수 있도록 rule을 만들어 줍니다. Firewall > Rules > WAN 탭에서 Add 버튼을 눌러 먼저 Pass rule을 만들어줍니다. Sources는 ManagementAccess로 설정하고, Destination은 This firewall, 포트는 ManagementPorts로 설정하여 이 방화벽에 management IP가 management Port로 접근하면 허용하도록 만들어줍니다.

그 후 Blcok rule을 만들어 management ip 외의 모든 ip는 차단하도록 만들어 줍니다. 마찬가지로 Firewall > Rules > WAN 탭에서 Add 버튼을 누르고 Sources는 any로 설정하여 모든 ip에 대한 rule을 만들어주시고 Destination은 Pass rule과 동일하게 설정해줍니다.

마지막으로 두 rule의 순서를 위와같이 Pass rule이 위로 오게 변경 해 주신 후 Apply Changes를 눌러주시면 이제 WAN ip로 외부에서 접속 하실 수 있습니다. pfSense rule은 위에서부터 아래 순서로 적용되기 때문에 꼭 순서를 Pass rule이 위로 오게 설정해주세요.

마치며

이렇게 pfSense를 사용하기 위한 모든 준비가 끝났습니다. pfSense는 기본적인 방화벽 룰 이외에도 패키지를 설치하여 다양한 기능을 사용 할 수 있습니다. 다음 포스팅에서는 pfSense 및 패키지의 다양한 기능을 소개하도록 하겠습니다.

Github 블로그 구축하기 (2)

2022-01-24T00:00:00+00:00

Github 블로그 구축하기 (2) - 커스터마이징

1. Github 블로그 구축하기 (1) - Github 블로그 생성

2. Github 블로그 구축하기 (2) - 커스터마이징

구조 파악하기

jekyll 디렉토리 구조 ¹

.
├── _config.yml
├── _data
│   └── members.yml
├── _drafts
│   ├── begin-with-the-crazy-ideas.md
│   └── on-simplicity-in-technology.md
├── _includes
│   ├── footer.html
│   └── header.html
├── _layouts
│   ├── default.html
│   └── post.html
├── _posts
│   ├── 2007-10-29-why-every-programmer-should-play-nethack.md
│   └── 2009-04-26-barcamp-boston-4-roundup.md
├── _sass
│   ├── _base.scss
│   └── _layout.scss
├── _site
├── .jekyll-metadata
└── index.html # 올바른 머리말을 가진 'index.md' 도 가능

우선 커스터마이징을 위해서는 jekyll 디렉토리 구조를 파악 할 필요가 있습니다. 디렉토리 구조에 관해서는 jekyll 공식 홈페이지에 자세히 나와있습니다. 모든 디렉토리를 다 확인 할 필요는 없을 것 같고 필요한 부분은 공식 문서의 디렉토리 설명을 참조하였습니다.

_config.yml : 환경설정 정보를 보관한다. 명령어를 실행할 때 여러가지 옵션들을 추가할 수도 있지만, 그렇게 따로 외우는 것보다 이 파일에 정의해두는게 더 편리하다.
_data : 사이트에서 사용 할 데이터를 적절한 포맷으로 정리하는 디렉토리이다.
_includes : 재사용하기 위한 파일을 담는 디렉토리로서, 필요에 따라 포스트나 레이아웃에 쉽게 삽입할 수 있다.
_posts : 한마디로 말하면, 당신의 컨텐츠다. 중요한 것은 파일들의 명명규칙인데, 반드시 이 형식을 따라야 한다: YEAR-MONTH-DAY-title.MARKUP. 고유주소는 포스트 별로 각각 정의할 수 있지만, 날짜와 마크업 언어 종류는 오로지 파일명에 의해 결정됩니다.

주로 제가 수정 할 파일은 이렇게 네 개 인것 같습니다.

liquid 언어란?

liquid는 Shopify²가 개발한 Ruby로 작성된 오픈소스 템플릿 언어이며 주로 jeykyll 에서 템플릿을 처리 할 때 사용합니다. 일반적으로 Liquid에서는 내용 출력 시 중괄호 2개를 사용하며 %를 이용하여 논리 연산을 합니다. jekyll 파일 이것 저것 열어보다 보면 뜬금없이 중괄호 2개로 감싸져있는 언어를 볼 수 있는데 이것이 liquid 언어입니다.

블로그 수정하기

자, 이제 디렉토리 구조도 알았고 liquid 언어도 알았으니 본격적으로 수정을 해봅시다. 일단 메뉴를 담고있는 헤더같은 경우엔 재사용을 하는 경우가 많으니 _include에 있을 확률이 매우 높습니다. 따라서 _include/_layout.html 을 가장먼저 살펴보았습니다.

<header id="header" class="header" itemscope itemtype="http://schema.org/WPHeader">
      <div class="header-inner"> {% include _partials/header.html %} </div>
</header>

크롬 개발자 도구로 html 코드를 확인 후 비교 했을 때 _includes/_partials/header.html에서 메뉴 구성을 하는 걸 확인 할 수 있었습니다.

<nav class="site-nav">
  .
  .
  .
   {% if site.menu %}
    <ul id="menu" class="menu">
      {% for name_path in site.menu %}
        {% assign name = name_path[0] %}
        {% assign path = name_path[1] %}
        {% assign itemName = name | downcase %}
        <li class="menu-item menu-item-">
          <a href="" rel="section">
            {% if site.menu_icons.enable %}
              <i class="menu-item-icon fa fa-fw fa-question-circle"></i> <br />
            {% endif %}
            {{ __.menu[name] }}
          </a>
        </li>
      {% endfor %}
      .
      .
      . 
    </ul>
  {% endif %}
  .
  .
  .
</nav>

.
.
.
menu:
  home: /
  #categories: /categories/
  about: /about/
  archives: /archives/
  #tags: /tags/
  #sitemap: /sitemap.xml
  #commonweal: /404.html

menu_icons:
  enable: true
  KeyMapsToMenuItemKey: NameOfTheIconFromFontAwesome
  home: home
  about: user
  categories: th
  schedule: calendar
  tags: tags
  archives: archive
  sitemap: sitemap
  commonweal: heartbeat
.
.
.

html 태그와 비교 해 보니 이 부분이 바로 제가 원하는 부분입니다. site.menu라는 liquid 변수로 config 파일에 있는 menu 항목을 불러와 메뉴를 구성하는 것을 확인 할 수 있었습니다. 저는 현재 about 페이지가 필요하니 about에 주석을 해제하도록 합시다. 또 카테고리와 태그 대신, 직접 커스텀 한 메뉴를 넣을 것이기 때문에 categories와 tags는 주석처리 해주도록 합니다.

그렇다면 위와같이 기존에 있던 categories과 tag는 사라지고 대신 about 메뉴가 생긴 것을 볼 수 있습니다.

메뉴 아이콘은 https://fontawesome.com/v4.7/icons/ 사이트를 참고하여 원하는 아이콘의 이름을 menu_icons 항목에 넣어주면 자동으로 삽입됩니다.

.
.
.
# Local search
local_search:
  enable: true
  # if auto, trigger search by changing input
  # if manual, trigger search by pressing enter key or search button
  trigger: auto
  # show top n results per article, show all results by setting to -1
  top_n_per_article: 1
.
.
.

또한 원활한 블로그 탐방을 위해 블로그 내 검색 기능도 추가하려면 local_search 부분에서 enable 부분을 true로 변경 해 줍니다.

검색 기능이 활성화 된 것을 확인 할 수 있습니다.

블로그 커스터마이징하기

그럼 이제 본격적으로 커스터마이징 하기 위해 구조를 설계 해 봅시다. 기존의 메뉴를 그대로 쓰기 보다는 타 블로그 사이트 처럼 제가 원하는 메뉴를 추가하여 카테고리를 나누려고 합니다. category와 tag를 이용하여 category를 메인 메뉴로, tag를 서브 메뉴로 써서 기존 메뉴보다 다양하게 글을 분류할 수 있고 정적 페이지이지만 동적으로 메뉴를 추가할 수 있도록 수정 할 예정입니다. 또한 상단 header에는 category와 tag를 이용한 드롭다운 메뉴를 만들고 우측 사이드바에도 custom 공간에 해당 메뉴를 만들어 조금 더 메뉴 이동이 쉽도록 만들어 보려고 합니다.

커스텀 메뉴 추가하기

우선 main menu로 사용 할 categories를 헤더에 출력해봅시다.

.
.
.
    <ul id="menu" class="menu">
      {% for name_path in site.menu %}
        {% assign name = name_path[0] %}
        {% assign path = name_path[1] %}
        {% assign itemName = name | downcase %}
        <li class="menu-item menu-item-{{ itemName }}">
          <a href="{{ path | relative_url }}" rel="section">
            {% if site.menu_icons.enable %}
              <i class="menu-item-icon fa fa-fw fa-{{site.menu_icons[itemName] | default: 'question-circle' | downcase }}"></i> <br />
            {% endif %}
            {{ __.menu[name] }}
          </a>
        </li>
      {% endfor %}
.
.
.

위 코드를 보니 site.menu에서 메뉴 정보를 불러오고, __.menu[name]에서 메뉴 이름을 출력 하는 것 같습니다. site.menu에 project 메뉴 정보를 추가하기 위해 _config.yml 파일을 수정합니다. project 메뉴는 category의 project와 연결 할 예정이기 때문에, /category/#/project 링크와 연결해줍니다.

.
.
.
menu:
  home: /
  #categories: /categories/
  about: /about/
  archives: /archives/
  #tags: /tags/
  project: /category/#/project
  #sitemap: /sitemap.xml
  #commonweal: /404.html

  menu_icons:
  enable: true
  KeyMapsToMenuItemKey: NameOfTheIconFromFontAwesome
  home: home
  about: user
  categories: th
  schedule: calendar
  tags: tags
  archives: archive
  sitemap: sitemap
  commonweal: heartbeat
  project: pencil-square
.
.
.

config 파일 수정 후 메뉴 탭을 보시면 아이콘만 출력되고 메뉴의 이름은 출력되지 않는 것을 확인할 수 있습니다. 해당 메뉴 이름 출력 부분은 위 코드상에서 ``에 해당되는데 해당 변수에 project 가 선언되지 않아 출력이 안되는 것 입니다. 따라서 변수 선언을 해주어야 하는데, 해당 변수는 _data/default.yml 아래에서 선언 할 수 있습니다.

.
.
.
menu:
  home: Home
  archives: Archives
  categories: Categories
  tags: Tags
  about: About
  search: Search
  schedule: Schedule
  sitemap: Sitemap
  commonweal: Commonweal 404
  project: Project
.
.
.

위 작업까지 마치고 나면 project 메뉴가 정상적으로 추가 된 것을 확인 할 수 있습니다.

드롭다운 메뉴 만들기

드롭다운 메뉴를 만들기 위해서는 먼저 tag로 리스트를 만들어야 합니다. 메뉴 아래에 해당 카테고리 아래에 있는 tag 정보를 리스트로 만들어 출력하는 코드를 추가합니다.

.
.
.
{% for name_path in site.menu %}
  {% assign name = name_path[0] %}
  {% assign path = name_path[1] %}
  {% assign itemName = name | downcase %}
  <li class="menu-item menu-item-{{ itemName }}">
    <a href="{{ path | relative_url }}" rel="section">
    {% if site.menu_icons.enable %}
      <i class="menu-item-icon fa fa-fw fa-{{site.menu_icons[itemName] | default: 'question-circle' | downcase }}"></i> <br />
    {% endif %}
    {{ __.menu[name] }}
    </a>
    {% for post in site.categories[name] %}
      {% if post.tags %}
        {% assign tag_list = tag_list | concat: post.tags | uniq %}
      {% endif %}
    {% endfor %}
    {% if site.categories[name] %}
        <ul class="dropdown-content" >
        {% for tag in tag_list %}  
          {% assign tag_url_encode = tag | url_encode | replace: '+', '%20' %}
            <li class="dropdown-list">
              <a class = "dropdown-item" href="{{ '/tag/#/' | relative_url | append: tag_url_encode }}">{{ tag }}</a>
            </li> 
        {% endfor %}
        </ul>
      {% endif%}
  </li>
{% endfor %}
.
.
.

먼저 해당 메뉴와 동일한 이름을 가진 카테고리에 있는 포스트를 전부 검사하여 태그가 있는지 검사하고, 태그가 있으면 해당 태그를 리스트에 저장 후에 리스트를 출력하는 코드를 작성하였습니다.

이렇게 코드를 작성 한 후에 블로그에 적용시켜보면 카테고리 아래 태그 리스트가 생성되는 것을 확인 할 수 있습니다.

이제 이것을 드롭다운 메뉴로 만들기 위해 CSS를 적용시켜 보겠습니다. 메뉴 css는 _sass/_common/components/header/header.scss 경로에 있습니다.

@at-root %menu-a-hover { border-bottom-color: $menu-link-hover-border; }
&:hover { 
      @extend %menu-a-hover; 
      -webkit-transform: scaleX(1);
      -ms-transform: scaleX(1);
      transform: scaleX(1); // reveal
    }
  }

  .fa { margin-right: 5px; }
}

.use-motion .menu-item { opacity: 0; }

.dropdown-content {
  display: none;
  position: absolute;
  background-color: darken(#ffffff, 3%);
  min-width: 100%;
  box-shadow: 5px;
  box-sizing: border-box;

  a {
    display: block;
    font-size: 13px;
    line-height: inherit;
    border-bottom: 1px solid $menu-link-border;
    transition-property: border-color;
    @include the-transition();

    @at-root %menu-a-hover { border-bottom-color: $menu-link-hover-border; }
    &:hover { 
      @extend %menu-a-hover; 
    }
  }
}

.menu-item:hover .dropdown-content {
  padding: 0px;
  margin: 0px;
  min-width: 100%;
  display: block;
  // font-size: 17px;
}

.dropdown-list{
  list-style: none;
  position: relative;
}

.dropdown-item {
  padding: 0px;
  margin: 0px;
  font-size: 15px;
}

.dropdown-item:after {
  padding: 0px;
  margin: 0px;
  display:block;
  content: '';
  border-bottom: solid 3px #2b2a2a;  
  transform: scaleX(0);  
  transition: transform 250ms ease-in-out;
}

.dropdown-item:hover:after { 
  padding: 0px;
  margin: 0px;
  transform: scaleX(1); 
  min-width: 100%;
}

저는 css를 잘 모르기 때문에 인터넷에 있는 드롭다운 메뉴 css를 적당히 짜집기 해서 작성하였습니다. 핵심은 메뉴에 커서를 가져다 대면 숨겨져있던 tag 리스트를 띄우는 것입니다. 또한 숨겨져있던 tag 리스트가 뜰 때 포스트가 해당 리스트를 가리면 안되므로 position과 z-index를 적절하게 설정하여 리스트가 제일 앞에 뜰 수 있게끔 설정합니다.

설정이 완료되면 위와 같이 메뉴 아래 태그 리스트가 드롭다운 메뉴로 활성화되는 것을 확인 할 수 있습니다.

사이드 메뉴 만들기

포스트를 보는 중에도 메뉴를 빠르게 전환 할 수 있도록 사이드 메뉴를 만들어 봅시다. 이미 next 테마에는 커스텀 할 수 있는 side bar 공간이 있기 때문에, 남는 공간을 활용하여 만들어 봅시다. 경로는 _includes/_custom/sidebar.html 입니다.

<div class="side-custom">
{% if site.menu %}
<ul id="sidemenu" class="sidemenu">
  {% for name_path in site.menu %}
    {% assign name = name_path[0] %}
    {% assign path = name_path[1] %}
    {% assign itemName = name | downcase %}
    <li class="side-menu-item" id="side-menu-item-list">
      <a id="side-menu-item" href="{{ path | relative_url }}" rel="section">
        {{ __.menu[name] }}
      </a>
         {% for post in site.categories[name] %}
            {% if post.tags %}
               {% assign tag_list = tag_list | concat: post.tags | uniq %}
            {% endif %}
         {% endfor %}
         {% if site.categories[name] %}
         <ul class="side-dropdown-content" >
         {% for tag in tag_list %}
            {% assign tag_url_encode = tag | url_encode | replace: '+', '%20' %}
                  <li class="side-dropdown-item">
                     <a id="side-dropdown-item" href="{{ '/tag/#/' | relative_url | append: tag_url_encode }}">{{ tag }}</a>
                  </li>      
         {% endfor %}   
         </ul> 
         {% endif%}
    </li>
  {% endfor %}
</ul>
{% endif %}
</div>

드롭다운 메뉴를 만들 때의 코드와 거의 유사하기 때문에 따로 추가 설명을 적지는 않겠습니다. 작성한 코드를 바탕으로 css도 꾸며주면 사이드 메뉴도 완성입니다.

.sidemenu{
    -webkit-padding-start: 5px;

    li {
        list-style: none;
        padding: 5px 0px 5px 0px;
        margin-bottom: 0px;
        font-size: 15px;
        text-align: left;
        
    }

    a {
        border-bottom: none;
        text-decoration-line: none;
        text-decoration-style: none;
        text-decoration: none;
    }

    a:hover{
        color: #87d9ff;
    }

    .side-menu-item::before{
        display: inline-block;
        vertical-align: middle;
        //padding: 0px 5px 0px 0px;
    }
}
#side-menu-item-list{
    border-bottom: 0.5px solid #333333;
}

#side-menu-item-list:last-child{
    border-bottom: 0px;
}

#side-menu-item{
    font-weight: 400;
    color: #f5f5f5;
    padding-left: 10px;
    padding-bottom: 0px;
}

#side-menu-item:hover{
    color: #87d9ff;
}

.side-dropdown-content{
    padding-left: 20px;
    border-bottom: 0px;
}
.side-dropdown-item{
    height: 15px;
    border-bottom: 0px;
}

.side-dropdown-item::before {
    content: "-";
}

.side-dropdown-item::before:hover {
    color: #87d9ff;
}

.sidebar {
  .
  .
  .
  overflow: scroll;
  .
  .
  .

다른 side menu와의 혼동을 방지하기 위해 _sass/sidebar 경로 아래에 sidebar-custom.scss 파일을 생성하여 사이드메뉴 css를 따로 설정해줍니다. 또한 사이드 메뉴가 늘어나 잘리는것을 방지하기 위해 기존 sidebar div가 일정 크기를 벗어나게 되면 스크롤을 생성해주는 css도 넣어줍니다.

Overview를 확인해보시면 프로필 아래 커스텀 공간에 메뉴 리스트가 생성 된 것을 확인하실 수 있습니다.

마치며

생각보다 구조를 분석하고 커스터마이징 하는데에 시간이 오래 걸려 예상 했던 것 보다는 훨씬 늦어졌지만 그래도 원하는 대로 적절하게 커스터마이징이 된 것 같습니다. 추후에 더 수정하거나 추가 할 사항이 있으면 추가해가며 블로그를 꾸려나갈 예정입니다. 사실 블로그 커스터마이징 하는데 시간을 너무 오래 들여서 그냥 티스토리 블로그를 쓸까 후회도 많이 했지만 나름 원하는 기능을 넣고 나니 역시 직접 만들길 잘 했다는 생각이 듭니다. 다음에는 더 알차고 재밌는 포스팅을 하길 바라며 이만 글을 마치겠습니다.

https://jekyllrb-ko.github.io/docs/structure/ ↩
https://shopify.github.io/liquid/ ↩

Github 블로그 구축하기 (1)

2022-01-20T00:00:00+00:00

Github 블로그 구축하기 (1) - Github 블로그 생성

1. Github 블로그 구축하기 (1) - Github 블로그 생성

2. Github 블로그 구축하기 (2) - 커스터마이징

개요

블로그를 만든 이유

사실 블로그를 개설한 것이 이번이 처음은 아닙니다. 학교를 졸업하기 전부터 언젠가는 나만의 기술 블로그를 만들어야지 라고 생각은 하고 있었고 실제로 도메인을 하나 구매 후 웹호스팅 사이트를 이용해서 블로그를 개설한 적이 있었습니다. 하지만 막 학부생을 졸업한 시점에서 이렇다 할 제대로 된 프로젝트도 없었고¹ 과연 제가 어느 분야로 갈지 진로에 대한 확신도 없는 상태에서 무작정 블로그를 개설하다 보니 어떤 것을 업로드 해야 하고 어떻게 작성해야 할지 잘 알지 못했고, 디자인적인 부분도 욕심을 부리다 보니 결국 이도 저도 못하고 호스팅 기간이 만료되어 그대로 증발하고 말았습니다…

그렇다면 지금은 어떤가? DevOps라는 직업군을 알게 되고 DevOps가 되기로 마음먹었고 해당 직군으로 취직² 하였으며 회사 내에서 작고 큰 프로젝트들을 한두 개씩 맡기 시작했습니다. 이제 저의 강점이 어떤 것인지, 제가 흥미 있는 분야가 어떤 것인지, 제가 부족한 부분이 무엇인지 대충이나마 감을 잡기 시작했습니다. 따라서 회사를 다닌 지 약 2년이 조금 넘은 지금 시점이 블로그를 개설 하는 가장 적절한 시기라고 생각했습니다.

주로 시스템적인 부분과 개발 부분에서 제가 공부 한 것들, 진행한 프로젝트들에 대해 올릴 예정이며, 분석하고 얘기하는 것을 좋아하기 때문에 가끔 다른 분야에 관한 이야기도 포스팅할 예정입니다.

Github 블로그 만들기

Github 블로그를 선택한 이유

네이버 블로그, 카카오 티스토리, 워드프레스 등 블로그 플랫폼은 상당히 다양합니다. 그렇다면 많고 많은 블로그 종류 중에 Github 블로그³를 선택한 이유는 무엇일까요? 블로그를 만들기 전 고려했던 요소가 몇 가지 있습니다.

디자인적인 부분이나 메뉴 구성에서 커스터마이징이 쉬워야 한다.
플랫폼을 사용하는 사용자가 적당히 많아야 한다.
코드 쓰기가 편해야 한다.
무료여야 한다.

네이버 블로그나 카카오 티스토리는 블로그 구성이 쉽고 이용자도 많아서 포스팅하기가 쉽지만, 한정된 테마로 블로그를 꾸며야 하고 디자인적인 요소를 수정하기도 쉽지 않습니다. 워드프레스 역시 블로그 구축이 쉽고 커스터마이징을 할 수 있다는 장점이 있지만 직접 웹호스팅을 해야 하고 추가적인 기능을 이용하려면 요금을 내야 하는 단점이 있습니다. 노션같은 경우도 상당히 편집이 쉽고 디자인적인 부분도 마음에 들었지만 무료 버전은 한 파일에 최대 용량이 5MB라는 단점이 있었습니다.

Github 블로그는 위의 조건을 모두 만족하면서도 깃허브와의 연동이 쉽다는 장점이 있습니다. 물론 Github 블로그에도 단점은 있는데, git과 코딩에 대한 지식이 어느 정도 있어야 구축할 수 있습니다. 하지만 이런 점도 정보통신 분야를 전공하는 사람으로서 어느정도 전문성을 가진 점으로 다가왔고 새로운 지식을 습득하는 건 항상 재미있는 일이기 때문에 고민 않고 Github 블로그를 선택하였습니다. 무엇보다 직접 공부해서 구축했다고 말하면 간지가 나기 때문에 최종적으로 Github 블로그를 선택했습니다.

Github pages 주의 사항

Github 페이지를 사용 시 주의해야 할 사항 역시 분명히 존재합니다. 해당 내용은 Github pages에서 제공하는 주의사항에 관한 내용입니다. 잘 읽어보고 본인의 상황에 맞게 플랫폼을 선택하시길 바랍니다.

GitHub Pages 소스 저장소의 권장 제한은 1GB입니다.
게시 된 GitHub 페이지 사이트는 1GB를 초과 할 수 없습니다.
GitHub 페이지 사이트의 대역폭 제한은 한 달에 100GB입니다.
GitHub 페이지 사이트의 builds 제한은 시간당 10회 입니다.

사전 작업

저장소(repository) 만들기 ⁴

Github 블로그를 만들기 위해서는 우선 Github에 새로운 repository를 생성해야합니다. Github에 접속하여 새로운 repository를 생성합니다. 이 때 Repository name은 [github username].github.io 형식으로 생성해야 username.github.io 도메인으로 생성되는 Github 페이지에 접속 할 수 있습니다. Add a README file에 체크 후 생성하면 약 1분에서 5분 후에 README 파일의 내용이 보이는 username.github.io 페이지를 볼 수 있습니다. 자 이제 나만의 Github 블로그를 생성하기 위한 기본적인 작업이 끝났습니다.

블로그 생성

프레임워크 선택하기

Github Page는 Github에서 제공하는 정적사이트 (Static Website) 호스팅 서비스입니다. 잠깐 동적사이트와 정적사이트의 차이점이 무엇인지 알아봅시다. 정적사이트는 클라이언트가 웹서버로 요청을 보내고, 웹서버는 단순히 로컬 저장소에 저장되어있는 html, img, css 파일 등을 사용자에게 보여주는 방식입니다. 따라서 정적사이트는 단순히 기존에 만들어져있는 정보를 보여주는 것이기 때문에 컨텐츠가 거의 변경되지 않는 포트폴리오나 소개글 등에 적합합니다.

그에 반에 동적사이트는 클라이언트가 웹서버로 요청을 보내면, url로 들어온 정보를 통해 웹 어플리케이션에서 해당 정보에 맞는 처리를 한 후 데이터베이스에 있는 자료를 불러와 클라이언트에게 보여줍니다. 실시간으로 처리되어야 하는 댓글이나 로그인, 회원가입 기능 혹은 쇼핑몰 장바구니 등 상황에 맞게 페이지를 보여주어야 할 때 적합합니다.

이러한 정적 페이지를 간편하게 만들기 위해서는 프레임워크를 사용해야 합니다. 간단히 생각해서 워드프레스 같은 기능이라 보면 됩니다. 물론 디자인에 능하고 a부터 z까지 직접 구축할 수 있으면 프레임워크를 사용 할 필요가 없지만 우리는 시간이 없기 때문에 프레임워크를 이용해 사이트를 구축하도록 합시다.

정적 사이트를 구축하기 위한 프레임워크 역시 다양한 종류가 있습니다. Next.js, Hugo, Gatsby 등 쉽고 간편하고 훌륭한 프레임워크가 많이 있습니다. 저는 현재 가장 많이 사용하기도 하고 제공하는 테마도 다양하며 Github에서 공식적으로 지원하는 jekyll⁵을 이용하여 블로그를 구축 할 예정입니다. 무엇보다 지킬은 쉽게 구축하는 방법이 많이 알려져 있기 때문에 초보자가 따라하기 매우 쉽다는 장점이 있습니다. 각 프레임워크를 비교한 글은 구글에 검색하면 많이 나오기 때문에 굳이 따로 첨부하지는 않겠습니다. 특히 Gatsby 공식 홈페이지에 가면 타 프레임워크와 비교하여 개츠비가 어떤 장점이 있는지 나와있습니다.⁶

테마 선택하기

무료로 제공하는 지킬 테마는 어마어마하게 다양합니다. 아래 사이트에 접속하면 다양한 테마들을 볼 수 있으니 각자 마음에 드는 테마를 선택해서 적용하면 됩니다.

http://jekyllthemes.org/
https://jekyllthemes.io/free
http://themes.jekyllrc.org/
https://github.com/topics/jekyll-theme

테마를 선택 할 때 역시 몇가지 기준을 정해서 선택했는데,

디자인이 깔끔해야한다.
디자인 요소 중 사진적 요소가 적어야한다. (디자이너가 아니기 때문에 사진의 비중이 크면 부담스럽기 때문이다.)
메뉴 커스터마이징이 쉬워야한다.
반응형 웹이여야 한다.
시간대별로 글 목록을 볼 수 있는 메뉴가 있어야한다.
사이드바가 존재해야 한다.
사이트 가독성이 좋아야한다.
Github 최근 업데이트가 너무 옛날이면 안된다.

이 모든 사항을 만족하는 테마가 몇 개 없긴 했지만 이 중에서 추가적으로 원하는 기능은 커스터마이징 해서 사용하기로 하고 몇 가지 테마를 골라보았습니다.

NexT - https://simpleyyt.com/jekyll-theme-next/
Hyde - https://hyde.getpoole.com/
Lanyon - https://lanyon.getpoole.com/

셋 다 디자인도 깔끔하고 단순하며 위의 조건에 어느정도 충족하지만 그중에서도 NexT 테마를 선택한 이유는 디자인이 제일 예뻐서입니다. 다른 매력적인 테마도 많으니 데모 페이지를 보고 본인 취향의 테마를 신중히 정하면 됩니다. 자 아무튼 테마를 선택했으니 이제 테마를 적용해보도록 합시다.

테마 적용하기

테마를 선택하였으면 해당 테마의 repository로 이동 할 수 있는 링크가 있을 것입니다. NexT repository로 이동 후 테마를 zip 파일로 다운받은 후 압축을 풀어줍니다.

현재 서술할 적용법은 기본적으로 git-cmd를 기준으로 설명하는 것이기 때문에 기본적으로 git과 git 명령어를 사용 할 줄 안다는 전제하에 이야기 하겠습니다. 우선 github에서 아까 생성하였던 github 블로그 url을 복사해줍니다.

git clone https://github.com/HeyItsSPOON/heyitsspoon.github.io.git

git-cmd를 열어 작업 할 디렉토리로 이동 후 git clone 명령어를 이용해 해당 repository를 로컬 PC에 불러옵니다. 그 후 다운받은 테마를 repository에 복사합니다.

# Site
title: Hey It's SPOON!🥄
subtitle: SPOON'S WORKBENCH
description: SPOON'S WORKBENCH
author: Yuna Kim
# Support language: de, en, fr-FR, id, ja, ko, pt-BR, pt, ru, zh-Hans, zh-hk, zh-tw
language: en

# URL
## If your site is put in a subdirectory, set url as 'http://yoursite.com' and baseurl as '/child'
url: "https://heyitsspoon.github.io"
baseurl: ""

jekyll은 기본적으로 config.yml 파일에 있는 기본설정을 따라갑니다. 테마 적용을 위해 간단한 설정 변경 후에 push를 진행하도록 합시다.

title: 사이트의 타이틀
subtitle: 사이트의 서브타이틀
description: title과 동일하게 페이지 head에 표시 될 내용. 사용하는 테마가 있고 사용하지 않는 테마가 있다.
author: 사이트 작성자
language: 다국어 플러그인
url: 해당 사이트의 실제 url. 사이트에 url을 할당해서 실행한다. bundle exec jekyll serve를 사용하면 해당 설정은 무시되고 로컬에서 실행된다.
baseurl: url 뒤에 붙는 기본 경로. 주로 url의 최상위에 있지 않은 사이트를 만들 때 사용된다. 여기서는 최상위 루트에서 실행되므로 공백으로 비워둔다.

적용되는 부분이나 config 내용은 테마마다 다르므로 헷갈린다면 직접 적용하면서 변경해도 좋습니다. 일단 모든 테마마다 공통적으로 사용하는 기본 설정은 이정도이므로 변경 후에 적용하도록 합니다.

git add .
git commit -m "Theme apply"
git push

git-cmd로 현재 작업중인 repository 디렉토리로 이동 후에 바뀐 파일을 검사하고 commit 후에 push 해주도록 합니다.

그 후 다시 url로 접속 해보면 깔끔하게 적용 된 테마를 만날 수 있다.

Ruby 및 jekyll, bundler 설치

jekyll은 Ruby라는 컴퓨터언어로 만들어졌다. 따라서 해당 프레임워크를 제대로 다루기 위해서는 Ruby를 설치해야합니다. Ruby는 Ruby installer⁷ 페이지에서 쉽게 다운받을 수 있습니다.

해당 페이지에 들어가 개발자 키트가 포함된 버전을 자신의 운영체제 비트에 맞게 다운받습니다. 주의 할 점은 반드시 path에 추가하는 부분에 체크하고 설치를 진행하길 바랍니다. 추후에 따로 추가 할 수도 있지만 상당히 귀찮기 때문에 자동으로 추가 하도록합니다.

ruby --version

Ruby 설치가 완료되었으면 git-cmd에서 명령어로 제대로 설치되었는지 확인합니다. 아래와 같이 버전 정보가 나오면 제대로 설치 된 것입니다.

ruby 2.6.6p146 (2020-03-31 revision 67876) [x64-mingw32]

gem install bundler jekyll

이제 Ruby가 설치되었으므로 github 블로그 디렉토리로 이동해 gem 명령어를 통해 jekyll과 bundler를 설치합니다. gem이란 CentOS의 yum, ubuntu의 apt같은 개념으로 루비에서 쓰이는 라이브러리 패키지입니다. cmd 환경에서 쉽게 패키지를 다운로드 받을 수 있습니다.

bundler는 루비에서 gem 라이브러리 의존성을 위해 사용되는 패키지로 보통 테마를 받을 때 Gemfile이 함께 있는 걸 볼수가 있는데 이 Gemfile에 다양한 Gem이 등록되어있습니다. 이 Gemfile에 Gem을 추가해서 사용하기 위해 bundler를 설치합니다.

bundle install

bundle install로 Gem을 등록하도록 합니다.

주의사항

Bundler could not find compatible versions for gem "ruby ":
In Gemfile: ruby

github-pages was resolved to 193, which depends on
    listen (= 3.1.5) was resolved to 3.1.5, which depends on
    rb-inotify (~> 0.9, >= 0.9.7) was resolved to 0.9.10, which depends on
        ffi (>= 0.5.0, < 2) was resolved to 1.9.25, which depends on
        ruby  (>= 2.0, < 2.6) x64-mingw32
    
github-pages was resolved to 193, which depends on
    nokogiri (>= 1.8.2, < 2.0) was resolved to 1.8.5, which depends on
    ruby  (>= 2.2, < 2.6 x64-mingw32
      
Could not find gem 'ruby  (>= 2.0, < 2.6)', which is required by gem 'nokogiri
(>= 1.8.2, < 2.0)', in any of the relevant sources:
    the local ruby installation 

위와 같이 간혹 테마 적용 시 다운받은 테마 bundler 버전과 시스템에 설치된 bundler 버전이 맞지 않아 발생하는 오류가 있습니다.

해당 오류 발생 시 해결 방법은 두가지가 있는데, 테마 사이트 버전을 올리거나 시스템에 설치 된 버전을 변경하는 것입니다.

사이트 버전 변경 기존 repository에 있던 Gemfile.lock을 삭제하고 bundle install을 진행합니다.
```
bundle install
```
시스템에 설치된 버전 변경
```
bundler --version
gem uninstall bundler -v [현재 설치되어있는 bundler 버전]
gem install bundler -v [설치하고자 하는 bundler 버전]
```
bundler –version 명령어로 현재 설치되어있는 버전을 확인 후에 사이트에 맞는 버전으로 재설치 한 후 진행합니다.

로컬에서 블로그 실행하기

Github page는 git을 push한다고 바로바로 적용되는 것이 아니기 때문에 짧게는 거의 실시간으로 반영되기도 하고 길게는 5분이상이 걸릴 때도 있습니다. 이럴 때 bundler를 이용하여 page를 localhost에서 실행시켜 적용사항을 바로바로 확인 할 수 있습니다.

bundle exec jekyll serve

위 명령어를 실행 후 Server running… 이라는 결과가 나오면 localhost:4000 (혹은 127.0.0.1:4000) 으로 접속하여 실시간으로 변경 된 블로그를 확인 할 수 있습니다. 단 실제로 적용된 것은 아니니 꼭 수정 후에 git push를 이용해 제대로 github에 올려주도록 합시다.

bundle exec jekyll serve 명령어로 이미 로컬에서 블로그를 실행시키고 있는 와중에 블로그를 변경해도 바뀐 사항이 보이지 않으니 꼭 Ctrl+C로 명령어를 끝내고 다시 실행시켜 변경사항을 확인하도록 합시다.

마치며

블로그의 기초가 되는 뼈대를 만들었으니 다음 포스팅에선 본격적으로 커스터마이징을 진행 할 예정입니다. 부디 이번엔 일주일에 포스팅 한개 목표를 지키길 바라며 글을 마칩니다.

물론 학부생 때 진행했던 프로젝트는 있었지만 제대로 정리도 안 되어있을 뿐더러 어디에 게재하기도 민망한 수준이였습니다. ↩
정확히는 시스템 엔지니어로 입사했고 DevOps를 지향하고있습니다. ↩
정식 명칭은 Github page 입니다. ↩
https://pages.github.com/ ↩
https://jekyllrb-ko.github.io/ ↩
https://www.gatsbyjs.com/features/jamstack/gatsby-vs-jekyll-vs-hugo/ ↩
https://rubyinstaller.org/downloads/ ↩