Simple is Beautiful.

References: Do it! 코틀린 프로그래밍

변수 선언 키워드와 자료형 그리고 자료형 추론에 대해 알아봅니다.

1. 변수 선언 키워드: val과 var

변수는 val과 var 키워드를 이용하여 선언합니다. 

val: 최초로 지정한 변수의 값으로 초기화 하며 더이상 수정할 수 없습니다.

var: 초깃값이 있더라도 이후에 값을 변경할 수 있습니다.

val은 const와 같은 개념으로 보입니다.

2. 자료형을 이용한 변수의 선언

변수는 다음과 같이 선언합니다.

val name: String = "smoh"

"val"은 변수 선언 키워드입니다.

"name"은 변수의 이름입니다.

"String"은 변수의 자료형입니다.

"smoh"는 변수의 값 입니다.

3. 변수의 자료형 추론

자료형을 명시적으로 지정하지 않으면 코틀린이 초기화 한 값을 바탕으로 자료형을 자동으로 찾아줍니다.

val name = "smoh"

위와 같은 선언의 경우 코틀린이 "smoh"를 바탕으로 name의 자료형을 추론해 String으로 결정합니다.

crtl+shift+P를 누르면 해당 변수를 어떤 자료형으로 추론하였는지 확인할 수 있습니다.

단, 다음과 같은 경우는 허용되지 않습니다.

var name

위와 같은 경우는 추론해야할 대상이 존재하지 않으므로 자료형 추론이 불가능하며 에러를 발생시킵니다.

4. 자료형 검사

변수의 자료형을 알아내려면 is 키워드를 사용하면 됩니다.

fun main() {
    var num = 123
    if(num is Int) { println("num is int!") }
    if(num !is Int) { println("num is not Int!") }
}

결과값은 "num is Int!"를 출력합니다.

References: Do it! 코틀린 프로그래밍

사용자가 직접 정의한 클래스를 사용하는 방법을 알아봅니다.

1. 클래스정의.

프로젝트를 생성 후 패키지를 만듭니다. 그리고 그 아래 클래스를 하나 만들어 둡니다.

defineMyClass 패키지 아래 Person 클래스를 생성하였습니다.

이 클래스를 다른 패키지인 useMyClass의 메인함수에서 사용해 보겠습니다.

2. 클래스 사용하기.

Main.kt에 다음과 같이 코딩합니다.

package useMyClass

import defineMyClass.Person

fun main() {
    val user1 = Person("smoh", 28);
    println(user1.name)
    println(user1.age)
}

이후 실행하면 다음과 같은 결과값을 확인할 수 있습니다.

그런데 만약 useMyClass 패키지내에 Person클래스가 이미 존재하면 어떻게 쓸 수 있을까요 ?

이를 테스트하기 위해 useMyClass에도 Person클래스를 추가합니다. 그리고 다음과 같이 코딩합니다.

(** 물론 입력하는 자료형리 다르다면 똑똑한 컴파일러는 알아서 구분해주긴 합니다.)

package useMyClass
class Person(val name: String, val dob: Int)

이제 main에서 같은 패키지 내의 Person클래스를 사용해 보려고 합니다.

뭔가 문제가 생긴것을 볼 수 있습니다. user2는 같은 패키지 안에 있는 Person을 사용하고 싶은데 자동으로 defineMyClass 안에 있는 Person을 생성해 버립니다.

이 둘을 구분하여 쓰기 위해 "as"를 사용해 별명을 붙입니다.

코드를 다음과 같이 수정합니다.

as를 사용해 별도로 이름을 지정해 주면 같은 이름의 클래스를 구분할 수 있습니다.

References: Do it! 코틀린 프로그래밍

코틀린에서의 모듈, 패키지, 클래스 개념에 대해 알아봅니다.

1. 프로젝트.

최상단 개념입니다. 프로젝트는 모듈, 패키지, 클래스를 포함합니다.

한 프로젝트는 여러 모듈을 가질 수 있습니다.

처음 프로젝트 생성 후 좌측 리스트를 보면 기본적으로 프로젝트 단위로 구성을 볼 수 있습니다.

2. 모듈

프로젝트 바로 아래의 개념입니다. 모듈은 패키지와 클래스를 포함합니다.

한 모듈은 여러 패키지를 가질 수 있습니다.

프로젝트 우클릭 후 New > Module을 클릭해 모듈을 프로젝트 아래에 추가할 수 있습니다.

프로젝트 아래에 모듈이 추가된 것을 확인할 수 있습니다.

보기단위를 패키지로 바꾸면 좀 더 명확하게 구분지어 볼 수 있습니다.

3. 패키지

모듈의 아래 개념입니다.

기본(default)패키지와 사용자가 명명한 패키지가 있습니다.

이름이 별도로 지정되지 않은 파일의 경우 모두 기본 패키지에 속하게 됩니다.

모듈 아래 자동 생성된 src에 우클릭 후 New > Package를 클릭하면 패키지를 만들 수 있습니다.

패키지의 이름은 보통 사이트 이름을 뒤집어서 많이 씁니다. 

예를 들어 sub.domain.com인 경우 패키지 이름은 com.domain.sub이런식으로 짓습니다.

그리고 필요에따라 기능별로 뒤에 단어를 추가합니다.

예를 들어 com.domain.sub.do.somthing이런식으로 구분하면 관리가 좀 더 용이해집니다.

예시로 다음과 같이 패키지를 생성했습니다.

com.exampple.ktmodule패키지를 생성 후 실제 폴더가 어떻게 생성되었는지 확인해 봅시다.

[.]단위로 구분되어어 src 아래에 com\example\ktmodule폴더 순서로 생성된 것을 확인할 수 있습니다.

3-1. 기본패키지

기본패키지란 코틀린 프로그래밍에서 자주 사용되는 클래스와 함수등을 미리 만들어 둔 것으로 import를 별도로 사용하지 않아도 바로 사용할 수 있는것들 입니다.

기본패키지는 kotlin-stdlib-sources.jar에 위치합니다.

IntelliJ에서 String을 정의 한 후 String에 ctrl + B를 누르면 확인할 수 있습니다.

기본패키지는 다음과 같습니다.

kotlin.*

kotlin.annotation.*

kotlin.collections.*

kotlin.io.*

kotlin.ramges.*

kotlin.sequences.*

kotlin.text.*

4. 클래스

패키지 아래에 위치한 개념이며 실제 코틀린 파일에 정의됩니다.

위에 만든 패키지를 우클릭 해 새 코틀린 파일을 생성합니다.

생성한 코틀린 파일엔 다음과 같은 코드가 자동으로 입력된 것을 확인할 수 있습니다.

package com.example.ktmodule

이전에 만든 "HelloKotlin.kt" 파일을보면 차이가 있습니다.

fun main() {
    println("Hello kotlin!")
}

package의 유무를 확인할 수 있습니다.

package가 명시적으로 입력되지 않은 모든 파일(클래스)는 기본(default) 패키지에 속하게 됩니다.

실제 코틀린 파일의 위치를 보면 "HelloKotlin.kt"는 패키지 아래에 위치하지 않음을 확인할 수 있습니다.

같은 패키지 내에서 모든 클래스의 이름은 유일해야 합니다.

다르게 말하면 패키지가 다르면 같은 이름의 클래스 이름을 사용할 수 있습니다.

테스트를 해보겠습니다.

KotlinModule에 기본패키지에 코틀린 파일을 하나 추가합니다.

그 후 두 코틀린 파일에 다음과 같이 클래스를 정의해 봅시다.

class person(val name: String, val age: Int)

별 문제 없이 정의가 됩니다. 이제 package com.example.ktmodule를 주석처리 해 봅시다.

오류가 발생한 것을 확인할 수 있습니다.

"KotlinModuleClass.kt"파일의 Person 클래스를 KotlinModuleClass로 변경해 봅시다.

package com.example.ktmodule
class KotlinModuleClass(val name: String, val age: Int)

파일명과 클래스명이 같으면 해당 파일의 확장자가 숨김처리 됩니다.

Person 클래스를 갖고있는 DefaultKotlinClass는 .kt 확장자가 그대로 남아있음을 확인할 수 있습니다.

References: Do it! 코틀린 프로그래밍

진입점인 main함수의 매개변수 사용법을 알아보자.

1. 메인 함수의 매개변수 설정해보기.

fun main(args: Array<String>) {
    for(i in args) {
        println(i)
    }
}

위의 코드를 실행시켜 봅시다.

아무것도 안나오네요. 매개변수인 args에 아무런 값도 들어가있지 않기 때문입니다.

Run > Edit Configurations로 들어가봅시다.

Program arguments 항목이 보이시나요? 이 항목이 명령형 인자를 지정할 수 있는 항목입니다.

[Hello Kotlin !]을 입력해 봅니다.

2. 메인 함수의 매개변수 출력해보기.

다시한번 동일한 코드를 실행시켜 봅시다.

fun main(args: Array<String>) { 
    for(i in args) { 
        println(i) 
    } 
}

이제 결과값이 보이시나요?

정상적으로 출력됨을 확인할 수 있습니다.

References: Do it! 코틀린 프로그래밍

모든 개발의 첫 걸음 Hello world! 프로젝트입니다.

1. 프로젝트 생성.

IntelliJ를 열고 새 프로젝트를 생성합니다.

Kotlin > JVM | IDEA 를 골라줍니다.

프로젝트 정보를 입력합니다.

만약 Project SDK정보가 설치한 JDK정보와 다르다면 직접 폴더 경로를 지정해 줍니다.

2. 코틀린 파일 생성.

새 코틀린 파일을 생성합니다.

파일이름은 HelloKotlin으로 해줍니다.

3. Hello Kotlin!

다음과 같이 코딩합니다.

fun main() {

    println("Hello kotlin!")

}

이후 Run을 해봅니다.

정상적으로 메시지가 출력되는것을 확인할 수 있습니다.

References: Do it! 코틀린 프로그래밍

1. IDE 설치하기.

IDE는 IntelliJ를 사용합니다.

여기에서 다운받아 설치해 주세요.

2. JDK 설치하기.

JDK는 Azul의 OpenJDK인 Zulu를 사용합니다.

여기에서 다운받아 설치해 주세요.

설치 경로를 기억해 둡시다.

3. 환경변수 설정하기.

자바 환경변수를 설정할 차례입니다.

윈도우 + Pause 또는 제어판 > 시스템 및 보안 > 시스템으로 이동 후 고급 시스템 설정을 누릅니다.

고급탭으로 이동해 환경변수 창을 엽니다.

"JAVA_HOME" 시스템 변수를 추가합니다.

변수이름은 JAVA_HOME으로, 변수값은 기억해둔 JDK설치 경로를 입력해줍니다.

이제 추가한 시스템변수로 사용자 변수를 정의합니다.

사용자 변수에서 "Path"를 찾은 후 편집을 누릅니다.

환경 변수 편집창에서 새로만들기를 누른 후 "%JAVA_HOME%\bin"을 입력해줍니다.

JAVA_HOME 시스템 변수를 생성할 때 맨 뒤에 \를 추가해놨는지 확인합시다.

이후 CMD등을 통해 "java -version"을 입력해 설정이 제대로 되었는지 확인합니다.

정상적으로 설정되면 버전이 보입니다.

References: Choosing between Babel and TypeScript

다음의 내용은 위의 글을 번역한 내용입니다.

바벨과 타입 스크립트 중 어떤 걸 사용해야 할까?

Babel 7은 약 6 개월 전에 TypeScript 구문 지원이 내장되어 출하되었습니다. 즉, Babel을 사용하는 프로젝트는 이제 TypeScript 컴파일러로 빌드를 복잡하게 할 필요 없이 TypeScript를 사용할 수 있습니다.
그러나 Babel과 TypeScript 컴파일러를 사용하는 경우의 차이점은 무엇이고 당신의 프로젝트에 Babel 또는 TypeScript중 어떤 걸 사용해야 할까요?

Babel과 TypeScript의 차이점

TypeScript를 사용하고 TypeScript를 Babel과 사용하는 데는 몇 가지 중요한 차이점이 있습니다.
이 글에서는 가장 중요한 네 가지 차이점을 살펴 보겠습니다.

1. 타입 검사 없음

Babel은 당신의 화려한 TypeScript의 타입에 대해서는 신경 쓰지 않습니다. 타입들이 옳다는 것을 확인하지 않고 그냥 쓰레기통에 버립니다. 아래 예제는 Babel을 사용하여 오류나 경고 없이 컴파일되지만 TypeScript에서는 컴파일되지 않습니다.

const myCoolString : string = 9;

9는 확실히 문자열이 아닙니다.
바벨을 사용하면 타입이 정확하지 않더라도 코드를 컴파일할 수 있는 빠른 프로토 타이핑에 탁월한 방법이 될 수 있습니다.
타입스크립트를 사용해 당신이 타입을 정하는 데에 노력을 기울이는 중이라면, 어느 시점에 당신은 아마 그것이 옳았다는 것을 확인하기를 원할 것입니다.  운 좋게 큰 문제가 아닙니다. 에디터가 처리하도록 하거나, "tsc --noEmit"를 실행하여 아무것도 컴파일하지 않고 프로젝트를 typecheck 할 수 있습니다.

2. Const enums

기본적으로 TypeScript는 한 번에 전체 프로젝트를 컴파일하지만 Babel은 한 번에 하나의 파일 만 컴파일합니다.

즉, Babel은 TypeScript의 기능중 여러 파일을 읽어야 하는 기능을 지원하지 않습니다. 좋은 소식은 그리 많은 기능이 포함되는 건 아니라는 것입니다. 가장 널리 퍼진 것은 아마도 enum입니다.

const enum에 대해서는 TypeScript가 아무것도 컴파일 하지 않습니다. 그것을 사용하는 방법과 트랜스 파일 된 코드가 무엇인지 살펴보겠습니다.

const enum FRUITS {
   APPLE = 'APPLE',
   PEAR = 'PEAR',
}

if (someString === FRUITS.APPLE){
   console.log("This is an apple!");
}

다음의 짧은 문장이 트랜스 파일된 코드입니다.

if (someString === "APPLE" /* APPLE */) {
   console.log("This is an apple!");
}

빵! 전체 enum 구조가 없어졌으며 TypeScript는 FRUITS.APPLE을 "APPLE"값으로 간단히 설명합니다.

하지만 이 const 열거 형을 내보내고 다른 파일에서 사용하려고 하면 어떻게 될까요? Babel은 한 번에 하나의 파일에만 액세스 할 수 있기 때문에 다른 파일에서 FRUITS.APPLE을 인라인 할 수 없습니다. 대신 단순히 오류가 발생합니다.

이것은 그리 심각하지 않습니다. Const enum은 대개 Babel이 잘 지원하는 일반 열거 형의 성능을 최적화하는 데에만 사용됩니다.

3. 데코레이터 및 메타 데이터

데코레이터들에 대해서 TypeScript는 조금 이릅니다. TypeScript가 데코레이터를 구현한 후에 데코레이터 제안이 여러 번 변경되었으며 아직 마무리되지 않았습니다.

이것이 의미하는 바는 현재 ECMAScript 스펙과 TypeScript가 데코레이터의 작동 방식을 직접 눈으로 보지 못한다는 것입니다. Babel의 플러그인은 ECMAScript 사양을 따르므로 Babel은 TypeScript와 동일한 방식으로 데코레이터를 컴파일하지 않습니다. 다행스럽게도 바벨은 legacy모드가 있어 예전의 동작으로 데코레이터를 컴파일할 수 있습니다.

바벨 플러그인 "@ babel / plugin-proposal-decorators"를 추가하고 레거시 옵션을 true로 설정하면 됩니다.

그러나 Babel은 제공하지 않지만 TypeScript에서 제공하는 데코레이터 기능 중 하나로 emitDecoratorMetadata가 있습니다.

TypeScript는 일반적으로 모든 타입 정보를 지우므로 런타임에 존재하지 않습니다. emitDecoratorMetadata는 데코레이터가 적용된 클래스 및 메서드에 대해 타입을 유지하는 기능입니다.

런타임에 타입을 사용하면 Dependency Injection과 TypeScript 타입을 SQL 데이터베이스의 타입에 매핑하는 등 모든 종류의 멋진 작업을 수행할 수 있습니다.

이 기능은 TypeORM, TypeGoose, inversifyJS 및이 기능에 따라 Angular의 종속성 주입 시스템과 같은 라이브러리와 함께 사용하면 상당히 유용합니다.

emitDecoratorMetadata의 부재는 Babel을 사용할 때 가장 큰 문제 일 것입니다. 이 기능에 의존하는 라이브러리 중 일부는 대단히 유용하지만 Babel과 함께 사용할 수는 없습니다.

4. 사용자 정의 변환

Babel은 TypeScript보다 훨씬 확장성이 뛰어납니다. 코드를 최적화하는 많은 플러그인이 있으며, 사용되지 않은 import, 인라인 상수 등을 제거 할 수 있습니다.

TypeScript에는 사용자 정의 변형을 허용하는 자체 Transformer API가 있지만 Babel의 환경에선 플러그인 선택의 폭이 넓으며 액세스가 훨씬 용이합니다.

사용자 정의 변환이 필요한 경우 Babel을 사용해야합니다. 다행스럽게도 대부분의 TypeScript 도구를 사용하면 TypeScript를 사용하고 나중에 바벨을 통해 코드를 실행하여 두 가지 장점을 모두 활용할 수 있습니다. 그러나 이것은 분명히 빌드 체인에 추가 복잡성을 가져옵니다.

기타 비 호환성 및 불일치

주로 문법 제약 및 레거시 TypeScript 기능과 관련된 몇 가지 다른 비 호환성이 있습니다. 누구에게나 방해물이 되어서는 안 되지만 여기에 발표되어 있습니다

성능

TypeScript와 Babel 7 모두로 React 앱을 컴파일하려했는데, 라이브 리로딩과 웜 캐시에서 중요한 차이점을 알 수 없었습니다. 벤치 마크는 ts-loader에 대한 것이었습니다. ts-loader는 TypeScript 용 두 개의 webpack 로더 중 가장 느린 것이었습니다 (다른 하나는 awesome-typescript-loader입니다).

물론, webpack을 구성하려고 시도하는 사람은 누구나 알고 있듯이 JavaScript 툴체인은 엄청나게 복잡합니다. 소스 맵 플러그인, 캐싱, 사용할 스레드 수 사이의 선택들이 계속됩니다. 단순한 벤치 마크는 전체 이야기를 고려할 수는 없지만, TypeScript 컴파일러에 비해 Babel을 사용하면 여러 배로 증가할 것으로 예상되는 경우 다른 곳에서 성능 향상을 찾아야 합니다.

당신은 무엇을 선택해야 합니까?

많은 자바 스크립트 개발자들처럼, 나는 반짝이고 새로운 것을 좋아합니다. 이 기사를 쓰기 시작했을 때 나는 Babel 로의 전환이 빌드 체인을 간소화하고 적은 단점이 있는 더 효과적인 빌드를 제공하기를 바랐습니다.

불행히도, 내 결론은 꽤 반대였습니다. 눈에 띄는 성능 향상은 없으며 단점도 원래 예상했던 것보다 훨씬 큽니다.

특히, 데코레이터 메타 데이터를 방출하지 않는 Babel은 내게 매우 적합하지 않습니다. 그 이유 하나만으로도 TypeScript 프로젝트가 있다면 Babel로 전환하는 것을 권장하지 않습니다.

Babel은 TypeScript를 처음 사용하거나 프로젝트를 점진적으로 마이그레이션 하려는 경우 교육용 바퀴로 유용할 수 있습니다. 어느 시점에서, 당신은 아마 훈련 바퀴를 벗어나고 싶을 것입니다.

Babel만 제공하는 사용자 정의 변형이 필요한 경우, 최상의 빌드 파이프 라인은 TypeScript 파일을 TypeScript 컴파일러로 전달한 다음 나중에 Babel로 전달하는 것입니다.

다소 복잡합니다. 하지만 누구도 자바 스크립트 빌드 툴체인이 쉽지 않다고 말한 적이 없습니다.

시놀로지 NAS를 이용한 개인 저장소 구축.

시놀로지 NAS를 이용해 Private Registry를 구축해 봅니다.

1. Registry 설치.

시놀로지 도커를 이용해 레지스트리를 설치합니다.

볼륨 설정은 다음과 같이 추가해줍니다.

포트는 기본포트를 사용하지 않고 5234번 포트를 사용했습니다.

2. 도메인 및 역방향 프록시 설정

저는 https://hub.smoh.kr/ 주소를 사용해 보겠습니다. 미리 도메인을 준비하시거나 그냥 IP주소를 사용하셔도 무방합니다. 확인해보지는 않았으나 QuickConnect를 사용해도 될 거 같긴 합니다.

역방향 프록시는 제어판 > 응용 프로그램 > 응용 프로그램 포털에 있습니다.

위와 같이 역방향 프록시를 설정해 줍니다.

이후 https://hub.smoh.kr/v2/_catalog 에 접속해 봅시다. 레지스트리가 정상적이라면 "{"repositories":[]}"와 같은 메시지를 확인할 수 있습니다. 그런데 인증서가 유효하지 않다고 나오네요. 

이제 인증서를 등록해 줍시다. 인증서는 제어판 > 연결성 > 보안 > 인증서 탭에서 추가할 수 있습니다. 여기선 Let's encrypt에서 인증서를 발급받아 사용하겠습니다.

매우 간단하게 인증서를 발급 받을 수 있습니다. 이제 구성에 들어가 hub.smoh.kr의 인증서를 새로 발급한 인증서로 변경해 줍니다.

이후 다시 https://hub.smoh.kr/v2/_catalog 에 접속해 보면 인증서가 제대로 적용된 것을 확인할 수 있습니다.

3. HTTP연결 자동으로 리디렉트 하기

위의 역방향 프록시를 보면 아시겠지만 현재 http://hub.smoh.kr/에 대한 처리가 없습니다. HTTP연결을 자동으로 HTTPS로 리디렉트 해주는 기능은 없으므로 DSM의 nginx에서 처리하도록 변경해 줍니다.

$ cd /usr/local/etc/nginx/sites-enabled
$ touch redirect.conf

파일명은 중요하지 않습니다. 적당한 이름의 conf파일을 만든 후 다음과 같이 수정합니다.

server {
  listen 80;
  server_name abc.domain.com;
  location / {
    rewrite ^(.*)$ https://abc.domain.com/$1 permanent;
  }
}

이후 nginx 리로드 합니다.

$ sudo nginx -s reload

그리고 http://hub.smoh.kr/을 통해 접속하면 자동으로 HTTPS로 리디렉트 되는 것을 확인할 수 있습니다.

4. 이미지 업로드 해보기

이제 테스트 이미지를 push하고 pull 해보도록 하겠습니다. 다른 접속지에서 도커 이미지를 내려받습니다.

$ docker pull ubuntu
$ docker images

우분투 이미지를 하나 다운받았습니다. 사진에서 보이듯이 앞서 레지스트리를 설치한 서버와는 다른 서버입니다. 이제 태그를 생성합니다.

$ docker tag ubuntu hub.smoh.kr/ubuntu
$ docker images

이미지가 새로 생성된걸 확인한 후 push를 시도합니다.

$ docker push hub.smoh.kr/ubuntu

이제 https://hub.smoh.kr/v2/_catalog로 이동하면 "{"repositories":["ubuntu"]}"와 같이 업로드한 이미지가 추가된 것을 확인할 수 있습니다.

가장 처음 폴더를 추가했던것을 기억하시나요 ? 그 폴더로 한번 이동해 봅시다.

사진과 같이 /docker/registry/v2 폴더가 새로 생성되었고 그 안에 업로드한 이미지가 저장된 것을 확인할 수 있습니다.

5. 유저 인증 추가

업로드도 확인했지만 만약 주소가 노출된 경우 어떤 유저도 해당 레지스트리에 접근할 수 있는 문제가 있습니다. 이 문제를 해결해 봅시다.

우선 시놀로지 도커에서 생성한 레지스트리 컨테이너를 종료합니다.  그후 다음과 같이 볼륨과 환경을 수정해줍니다.

설정 변경 후 컨테이너를 실행시키면 auth폴더 안에 htpasswd파일이 생성된 것을 확인할 수 있습니다. 이제 유저를 추가시키도록 합니다.

$ cd /volume1/docker/myReg
$ sudo docker run --entrypoint htpasswd registry -Bbn testuser testpassword > auth/htpasswd

위의 명령어를 시행하면 "testuser"계정이 "testpassword"의 암호를 갖은채 생성됩니다. 계정을 생성했으니 이제 https://hub.smoh.kr/v2/_catalog 를 통해 이미지 리스트를 불러오려고 시도해봅시다.

아까는 볼 수 없던 로그인창이 뜹니다. 로그인을 하면 정상적으로 이미지 리스트를 확인할 수 있습니다.

6. 이미지 다운로드

이제 다른 서버에서 이미지를 다운로드 받아봅시다.

$ docker pull hub.smoh.kr/ubuntu

위와 같이 인증관련 에러를 볼 수 있습니다. 이제 로그인을 한 뒤 이미지를 다운로드 받아보겠습니다.

$ docker login hub.smoh.kr
$ docker pull hub.smoh.kr/ubuntu

로그인 이후에 정상적으로 이미지를 다운받을 수 있습니다. 로그인 이후 ~/.docker/config.json에 인증정보가 저장되어 로그아웃하기 전까지 로그인 정보가 유지됩니다.

도커 개인 저장소 만들기

도커는 기본적으로 퍼블릭 저장소를 제공해 줍니다. 도커 허브에 로그인 하고 리포지토리를 확인하면 우측에 PUBLIC이라고 써있는걸 확인할 수 있습니다.

위의 이미지처럼 간단한 테스트 프로젝트면 상관없겠지만 공개되어선 안되는 프로젝트도 있죠. 다른사람은 접근할 수 없는 개인 저장소를 만들어 봅시다.

도커 허브 이용하기

도커 허브 서버를 이용하는 방법입니다. 별도 서버 구성이 필요하지 않으나 무료 계정에서는 하나만 사용할 수 있다는 단점이 있습니다.

Create Repository버튼을 클릭 후 Visibility옵션을 Private로 생성하면 끝입니다.

위와 같이 생성하면 간단하게 개인 저장소로 생성됩니다.

더 사용하고 싶으시면 돈을 내면 됩니다. Billing 메뉴의 Upgrade Plan 버튼을 클릭하면 사용할 개인저장소 개수에 따른 월별 금액이 나와있습니다.

개인 서버 이용하기

개인이 관리하고 있는 서버가 있거나, 다른 사유로 인해 직접 이미지들을 관리하고 싶다면 도커 레지스트리를 사용하시면 됩니다. 

도커 레지스트리(Docker Registry)는 이미지를 업로드하거나 다운로드 하는 공용/개인 저장소입니다. 도커 클라이언트를 통해 게시된 이미지를 검색해 다운로드 할 수 있습니다. 도커 허브가 제공하는 공개/개인 저장소들도 도커 레지스트리라고 할 수 있습니다.

우선 도커 레지스트리를 설치합니다.

$ docker pull registry:latest

$ docker images

이미지가 설치된 것을 확인한 후 컨테이너를 실행시킵니다.

$ docker run -name private-reg -d -p 5000:5000 registry:latest

각각의 명령어가 의미하는바는 별도로 언급하지 않겠습니다.

컨테이너가 제대로 동작하는지 확인해봅니다.

$ docker ps -l

레지스트리도 한번 확인해봅니다.

$ curl -X GET http://0.0.0.0:5000/v2/_catalog

정상적으로 응답이 오는것을 확인할 수 있습니다. 현재 생성한 리포지토리가 없으므로 공백이 리턴됩니다.

별도의 설정파일을 건드리지 않는 이상 로컬에 데이터를 저장합니다. 이에 대한 내용은 별도로 포스팅할 예정이며 공식 홈페이지를 참조해 주시기 바랍니다.

이제 레지스트리에 올릴 이미지를 준비합니다.

$ docker tag mintkiwi/test-image:0.1 0.0.0.0:5000/private-test-image

새로운 이미지가 제대로 생겼는지 확인 하고 push를 해봅니다.

$ docker push 0.0.0.0:5000/private-test-image

실패합니다. 연결이 거부되었다고 나옵니다. 레지스트리의 주소를 insecure-registries에 추가해줍시다. /etc/docker/daemon.json 파일을 다음과 같이 생성합니다.

Docker 17.x버전 이후부터는 Insecure registry를 수정하기 위해 daemon.json파일을 사용합니다. 이전버전은 /etc/init.d/docker파일의 DOCKER_OPTS를 수정해 주세요.

도커를 재시작하고 Insecure registries가 변경된 것을 확인합니다.

$ suto service docker restart
$ docker info

도커를 재시작했으므로 컨테이너를 실행하는것을 잊지마세요. 컨테이너를 실행하고 레지스트리에 push해봅시다.

$ docker push 0.0.0.0:5000/private-test-image:0.1

이제 정상적으로 push되는것을 확인할 수 있습니다. push완료 후에 레지스트리도 한번 조회해 보세요.

$ curl -X GET http://0.0.0.0:5000/v2/_catalog

제대로 업로드 된 것을 확인할 수 있습니다.

이제 업로드 한 이미지를 다운받아 볼 차례입니다. 기존 이미지를 지우고 pull을 통해 이미지를 다운받습니다.

$ docker rmi -f ####
$ docker pull 0.0.0.0:5000/private-test-image
$ docker images

정상적으로 다운로드 된 것을 확인할 수 있습니다.

우분투에서 도커 설치하기

우분투에서 도커CE버전을 설치해 봅니다.

우분투는 Ubuntu-server-18.04.2 버전을 사용했습니다.

쉘 스크립트를 이용한 도커 설치

2020.04.14. 추가.

마침 도커를 다시 설치할 일이 생겼습니다. 기존에 포스트를 보니 여러 복잡한 과정을 거쳐서 설치를 하도록 안내되어 있어 간단한 설치방법을 알려드립니다.

아래의 명령어를 실행시키면 바로 도커가 설치됩니다.

curl -fsSL https://get.docker.com/ | sudo sh

우분투 버전은 본 글 그대로인 18.04.2버전을 사용하였습니다.

도커 저장소 사용을 위한 패키지 설치

도커CE를 설치하기 전에 도커 저장소를 설정해야 합니다. 저장소 설정전에 필요한 패키지들을 설치합니다.

$sudo apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-common

위의 명령어를 통해 필요한 패키지들을 설치합니다.

도커 저장소 설정

도커의 공식 GPG키를 추가합니다.

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

정상적으로 처리되었는지 핑거프린트를 확인해 봅니다.

전체 핑거프린트는 다음과 같습니다: 9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88

여기서 마지막 8자리를 이용해 핑거프린트를 확인합니다.

$sudo apt-key fingerprint 0EBFCD88

핑거프린트를 확인 후 도커 저장소를 설정합니다

$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

저장소 설정 후 apt-get update를 잊지 마세요.

도커 CE 설치

$ sudo apt-get install docker-ce docker-ce-cli containerd.io

위의 명령어를 통해 도커 CE를 설치합니다.

설치 완료후 버전을 확인해 봅니다.

$ docker --version