이번에 이용중이던 서버호스팅사에서 서버가 SSD 하드웨어 고장으로 웹서버가 뻗어버렸습니다. ㅜㅜ
호스팅사의 대충처리때문에 장장 12시간 넘게 걸려서 복구했네요.
결국 애초에 조만간에 할 걸로 계획중이던 AWS (아마존웹서비스) 이전을 강제로 하게 되었습니다.
작업내용을 간단히 기록해 둡니다.
(더 보기…)이번에 이용중이던 서버호스팅사에서 서버가 SSD 하드웨어 고장으로 웹서버가 뻗어버렸습니다. ㅜㅜ
호스팅사의 대충처리때문에 장장 12시간 넘게 걸려서 복구했네요.
결국 애초에 조만간에 할 걸로 계획중이던 AWS (아마존웹서비스) 이전을 강제로 하게 되었습니다.
작업내용을 간단히 기록해 둡니다.
(더 보기…)docker의 경우 이미지 때문에 기본적으로 용량을 많이 차지한다. 그래서 기본 파티션이 용량이 작은 경우 추가로 붙인 볼륨의 파티션으로 경로를 변경해줄 필요가 있다.
먼저 아래와 같이 도커 설정 파일을 만든다.
$ sudo vi /etc/docker/daemon.json
설정 파일에 아래와 같은 json 형식으로 설정값을 지정하면 된다.
{
"graph": "/원하는/경로"
}
마지막으로 docker 서비스를 재시작하면 된다.
$ sudo systemctl restart docker
이제 해당 경로로 가보면 docker 에서 생성한 여러 폴더들을 볼 수 있다.
$ cd /원하는/경로
$ ls -al
total 0
drwx--x--x 14 root root 182 Jan 14 18:11 ./
drwxr-xr-x 3 root root 20 Jan 14 16:11 ../
drwx------ 2 root root 24 Jan 14 18:11 builder/
drwx------ 4 root root 92 Jan 14 18:11 buildkit/
drwx------ 2 root root 6 Jan 14 18:11 containers/
drwx------ 3 root root 22 Jan 14 18:11 image/
drwxr-x--- 3 root root 19 Jan 14 18:11 network/
drwx------ 3 root root 40 Jan 14 18:11 overlay2/
drwx------ 4 root root 32 Jan 14 18:11 plugins/
drwx------ 2 root root 6 Jan 14 18:11 runtimes/
drwx------ 2 root root 6 Jan 14 18:11 swarm/
drwx------ 2 root root 6 Jan 14 18:11 tmp/
drwx------ 2 root root 6 Jan 14 18:11 trust/
drwx------ 2 root root 25 Jan 14 18:11 volumes/
이런식으로 나오면 정상적으로 경로가 변경된 것이다.
이렇게 하면 서버의 용량 부족 문제를 해결할 수 있다 ^^
만약 한창 사용중이라면 docker 서비스를 중단한후 rsync 로 이동시키면 사용할 수 있을것으로 예상해 본다.
이래저래 써먹어 보려고 Docker 를 테스트 해보다 보니 이미지 생성, 강제 삭제 등을 여러번 하다가 의존성이 깨진건지 이상한 에러가 발생하기 시작했다.
$ docker-compose build
...
$ docker-compose up
Recreating 1695e5fd230f_www1204dcokr_web_1
ERROR: for web no such image: sha256:d6aeb5065849265e872ed19e5f5831b9bccc9ddd5f0d73d577c4102d27668a63: No such image: sha256:d6aeb5065849265e872ed19e5f5831b9bccc9ddd5f0d73d577c4102d27668a63
ERROR: Encountered errors while bringing up the project.
위와 같이 docker-compose 를 이용해 build 후 up 수행을 하면 이상한 에러를 뱉어내면서 중단된다.
이럴 때 해결할 수 있는 방법으로 아래와 같이 도커 리셋을 해보는 것이다. (root 계정으로 수행한다.)
# docker stop $(docker ps -a -q); docker rm $(docker ps -a -q); docker volume rm $(docker volume ls -qf dangling=true)
# docker network rm(docker network ls -q)
참조 : https://github.com/docker/compose/issues/3277#issuecomment-247964243
Module not found: Error: Can't resolve 'core-js/modules/es6.array.find' in '/src/.nuxt'
Docker 이미지를 만들다가 위와 같은 에러가 무수히 많이 나는 경우가 있다. 일반적인 개발환경에서는 오류가 발생하지 않는데 docker 이미지로 만들때만 오류가 발생해 참 힘들게 한다.
이를 해결 하기 위해서는 다음과 같이 core-js 패키지를 추가해 주면 해결 된다.
$ yarn add --dev core-js
이렇게 하고 다시 도커 이미지를 빌드하면 정상적으로 빌드가 된다.
이와 비슷한 오류가 있는데 그경우도 webpack 을 추가해주면 해결된다.
우분투 18.04 기준입니다.
스왑용량이 부족하거나 설치시 별도의 스왑파티션을 지정하지 않은 경우 간단히 스왑파일을 만들어서 사용할 수 있습니다.
기본적으로 시스템 관련 작업이므로 root 권한을 가지고 있는 경우로 가정하겠습니다.
$ sudo -i
다음과 같이 fallocate 를 이용해 원하는 용량의 스왑파일로 사용할 빈 파일을 만듭니다. (보통 장착된 램의 두배정도) 여기서는 간단히 8GiB 짜리 스왑을 생성해 보겠습니다.
# fallocate -l 8G /.swapfile
dd 명령어를 이용하는 방식도 있는데 fallocate 가 더 간편하고 빠르더군요.
보안을 위해 스왑 파일의 권한을 제한합니다.
# chmod 0600 /.swapfile
아래와 같이 스왑 파일을 생성합니다.
# mkswap /.swapfile
Setting up swapspace version 1, size = 8 GiB (8589930496 bytes)
no label, UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
현재 시스템에 스왑 파일 바로 적용해 봅니다.
# swapon /.swapfile
위와 같이 하고 free 명령어로 스왑이 적용되었는지 확인 할 수 있습니다.
# free -h
total used free shared buff/cache available
Mem: 15G 11G 173M 471M 3.8G 3.4G
스왑: 8.0G 0B 8.0G
이상태에서 리부팅하면 스왑파일 설정은 사라져 버립니다. ㅜㅜ; 시스템 리부팅시 자동으로 적용하기 위해서는 /etc/fstab을 아래와 같이 열어 편집합니다.
# vi /etc/fstab
(vi 편집기 사용법: Shift 키 + G (대문자 G) 를 누르고 o 를 입력하면 마지막줄에 새로운 줄을 추가해서 입력할 수 있습니다.)
아래 내용 을 맨 밑줄에 추가합니다.
/.swapfile none swap sw 0 0
(vi 편집기 사용법: 모두 적었으면 Esc 키를 누르고 나서 :wq 를 입력하고 엔터를 치면 저장할 수 있습니다.)
저장해 두면 이제 리부팅 후에도 스왑파일을 자동으로 시스템에서 스왑 영역으로 사용하게 됩니다.
Received disconnect from xxx.xxx.xxx.xxx port xx:2: Too many authentication failures
Authentication failed.
ssh 접속시 위와같이 오류가 뜨는 경우 해결하는 방법이다.
우선 SSH 키를 초기화 하면 된다. 접속하려는 클라이언트쪽에서 작업해야 합니다.
$ ssh-add -D
하지만 이렇게 해도 제대로 안돼는 경우 아래와 같은 오류메시지를 출력한다.
Could not open a connection to your authentication agent.
이렇게 되면 다음 명령을 실행해 주고 나서 다시 SSH 초기화를 호출해야 합니다.
$ exec ssh-agent bash
$ ssh-add -D
정상적으로 처리되면 아래와 같은 메시지를 출력합니다.
All identities removed.
이제 다시 ssh 접속을 해보면 정상적으로 잘 됩니다. ^^
기존에 이용하던 도메인 기관이 서비스가 불안하여 이번에 만료되는 도메인을 다른 기관으로 이전해 보았습니다.
이전하면서 절차들을 기록해 둡니다.
기존 도메인 기관을 A
새로 이전할 도메인 기관을 B라고 하겠습니다.
댓글을 달려면 로그인해야 합니다.