THINK-PRO BLOG

이 에러와 관련해서 이미 여러 블로그 포스팅이 있지만

한글로 된 포스팅 중에서 내 문제를 해결해준 경우는 없었다.

통상적으로 docker를 깔고 난 후

바로 docker ps 명령어 등을 하였을 때도 에러 없이 잘 나온다고 하면 다행인 것이지만,

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

혹은

Cannot connect to the Docker daemon at tcp:///localhost:2375. Is the docker daemon running?

와 같은 문제가 발생할 수 있다.

이 경우 아래 명령어들을 다 한 번씩 시도해보면 좋다.

우선, tcp localhost 2375가 나온다고 하면 DOCKER_HOST 환경변수가 알게 모르게 세팅되어 있는 경우가 있다. WSL 환경에서 도커를 세팅하고자 한다면 localhost:2375에 연결해두어야 하지만, 순수한 우분투 환경이라면 그렇게 하지 않아도 된다. 따라서 아래 명령어로 환경변수를 제거한다. 

unset DOCKER_HOST
unset DOCKER_TLS_VERIFY
unset DOCKER_TLS_PATH

위 명령어를 수행한 후에 다시금 "docker ps" 를 실행해보자. 그렇게 하면 적어도 tcp 에러가 아니라 unix~~ 에러로 변경되었을 것이다. 이때 해결이 그냥 잘되었으면 끝.

이제 at unix:///var/.... 까지 왔다면 그 다음에는 dockerd 명령어를 실행해보거나 아니면 status restart를 해보면 된다.

다른 블로그에서는 그냥 systemctl start랑 enable을 하라고 하지만, 이미 잘 켜져 있는 상태에서는 의미가 없다.

나의 경우 start와 enable로는 해결이 안되었지만 restart로는 해결이 되었다.

$ sudo dockerd

혹은

$ sudo service docker restart

git clone XXX 를 할 때, 

Cloning into '...' ...
fatal: unable to access 'XXX': Problem with the SSL CA cert (path? access rights?)

와 같은 문제가 발생하곤 한다.

이러한 문제를 해결하기 위해서는

cacert.pem 파일을 다운로드 받고 (https://curl.haxx.se/docs/caextract.html) 혹은 아래의 wget 명령어를 이용한다.

그리고 해당 파일을 ~/.ssh 등에 옮긴다. 다른 곳에 옮겨도 되지만, 여기서는 ~/.ssh에 옮겨두겠다.

wget https://curl.haxx.se/ca/cacert.pem
mv cacert.pem ~/.ssh

cacert.pem 파일을 확보했다면 해당 파일의 주소를 기억하고, 아래의 명령어를 입력한다.

~/.ssh가 아닌 다른 곳에 파일을 복사해두었다면 그 주소로 변경해야 한다.

git config --global http.sslBackend "openssl"
git config --global http.sslCAInfo ~/.ssh/cacert.pem

최적의 소프트웨어란 구체적인 목적이나 상황, 환경에 따라 다를 수 있다. 마찬가지로 어떤 소프트웨어 설계가 더 좋은 것이냐 하는 것도 구체적인 목적이나 상황, 환경에 따라 달라질 수 있다. 그럼에도 많은 전문가에 의하면 다음과 같은 특성을 갖추어야 좋은 소프트웨어 설계라고 말한다.

1. 이해 용이성 Unerstandability

전체 소프트웨어나 개별 구성 요소에 대해 쉽게 이해할 수 있어야 한다.

2. 수정 용이성 Modifiability or Flexibility

요구 사항의 변경에 따른 수정이 용이해야 한다.

3. 관리 용이성 Maintainability

소프트웨어 유지, 보수, 관리 단게에서 버그 수정이나 장애 대처, 요구 사항 변경, 성능 향상 등의 이유로 소프트웨어를 수정해야 할 경우 이를 쉽게 수행할 수 있어야 한다.

4. 재사용 용이성 Reusability

개발된 소프트웨어 구성 요소들을 다른 소프트웨어를 개발할 때 손쉽게 재사용 가능해야 한다.

5. 테스트 용이성 Testability

소프트웨어가 원하는 동작이나 기능을 수행하는지 테스트하기 쉬워야 한다.

6. 높은 안전성 Reliability

소프트웨어가 오류없이 원하는 작업을 수행할 수 있는 확률이 충분히 높아야 한다.

git commit 메세지를 설정하는 에디터가 기본적으로는 nano 에디터일 텐데, nano에디터에는 익숙하지 않아서 vim으로 바꿨었다. vim으로 바꾸는 커맨드는 다음과 같다.

하지만, vim도 뭔가 한글 작성시에는 느리게 동작하는 불편함때문에, 이쁜 에디터 중 하나인 sublime text를 사용하기로 했다.

sublime text를 git의 commit 메시지 에디터로 사용하려면 다음과 같은 커맨드를 터미널에 입력하면 된다.

일반적으로 변수를 상수화시킬 떄 사용하는 예약어로 const키워드를 사용하곤 한다. 그런데, const키워드를 클래스의 멤버함수와 객체에도 사용할 수 있다. 이 경우 어떻게 사용되는지 알아보도록 하자.

1. const 멤버함수

멤버함수에 const를 사용하는 이유는 객체의 멤버변수를 변경시킬 수 없도록 하기 위해서이다.

예를 들어, Get함수의 경우 일반적으로는 private 멤버변수를 반환하는 역할만 하지, 그 멤버변수를 수정하는 일은 절대 없어야 한다.

위와 같이 GetX, GetY 함수는 단순히 private member 변수인 x_, y_의 값을 반환하기만 할 뿐 그 값을 수정하거나 변경하는 일이 없다. 따라서 이러한 함수에는 const키워드를 붙여주는 것이 옳다.

const 키워드가 붙은 const 멤버함수는 객체의 멤버변수를 변경할 수 없는 읽기 전용 함수가 된다. 또한 const 멤버함수는 const로 지정되지 않은 다른 멤버 함수를 호출할 수 없다. 왜냐하면 읽기 전용으로 지정된 const멤버함수에서 const로 지정되지 않은 멤버함수를 호출하게 되면 간접적으로 객체의 멤버변수를 변경시킬수도 있기 때문이다. 

따라서, 앞으로 GetX, GetY와 같은 함수는 const 멤버함수로 선언하는 것이 바람직하다. (그러지 않아도 컴파일 에러는 발생하지 않지만, 코드를 좀 더 견고하고 안전하게 만들기 위해서 필요한 키워드인 것이다.)

참고로 생성자와 소멸자는 const 예약어를 사용할 수 없다. 생성자와 소멸자는 항상 객체의 데이터를 변경시켜야 하기 때문이다.

2. const 객체

멤버변수나 멤버함수 뿐만 아니라 객체에도 const 키워드를 사용할 수 있다. 객체 생성시에 const 키워드를 사용하면, 그 객체는 상수로 취급되어 초기화된 데이터 외의 다른 데이터로 변경할 수 없다. 

위와 같은 코드는 컴파일 에러를 발생시킨다. 왜냐하면 SetX, SetY의 멤버함수에서 x_, y_ 멤버 변수값을 변경하려고 하기 때문이다. const키워드가 붙은 객체 인스턴스는 그 멤버변수의 값이 변경되지 않는다.

이러한 논리로 보건대, const 객체는 당연하게도 const 멤버함수만을 제대로 사용할 수 있다. const키워드가 없는 멤버함수는 멤버 변수의 값을 변경할 가능성이 있기 때문에, 호출을 시도하더라도 대부분은 컴파일 에러가 날 것이다.

c++언어에서는 인라인 함수라는 것을 제공한다. 인라인이라는 의미는 코드 라인 자체가 안으로 들어간다는 뜻. 즉, 함수의 내용을 호출을 통해서 실행시키는 것이 아니라, 호출하는 코드 자체가 함수 내용의 코드가 되는 효과가 된다는 점이다. 바로 이해한 사람도 있겠지만 아닐 수도 있으니, 예를 들자면...

와 같은 코드가 다음과 같이 바뀌게 된다는 뜻이다.

눈치챘는가? 인라인 함수는 성능 향상을 위한 것이다. 물론 이렇게 바꿈으로써 실행 코드가 늘어날 수 있다는 단점이 있다. 따라서 인라인 함수는 코드는 작지만(1~3줄 정도) 자주 호출되지 않는 경우에 주로 사용하는 것이 좋다.

| 인라인 함수의 장점

인라인함수는 #define 매크로와 기능이 유사하지만, 인라인 함수만의 장점이 있다.

| 인라인 함수의 단점

인라인 함수를 사용함으로써 성능의 향상과 매크로의 부작용을 해결할 수 있다고 하지만, 인라인 함수를 너무 남발하게 되면 실행 코드 자체가 커지게 되는 단점이 있다. 그리고 인라인 함수의 모토는 1~3줄 정도의 짧은 코드를 함수화시킴으로써 효율성의 낭비를 막고자 함이었는데, 코드가 5줄 이상이 되어버린다면 굳이 인라인 함수를 사용할 이유가 없다.