우분투 17.10 이상에서 IP 설정하기

우분투 17.10부터는 여태까지 우리가 쓰던 NetworkManager 에서 netplan 이 기본값으로 변경됐다.
근데 한국에서 몇몇 리눅스 진영에서 “우분투 17.10 부터 netplan으로 바꾼다더라” 외에는 아무런 정보가 없다.

하긴… 신문물을 거부하는 김치새끼들이 뭐 그렇지 뭐. 그러면서 iOS 운영체제 알파만 나와도 하악하악…

어쨌든, 어쩌다 보니 깐 사람이던 쓰고 싶어서 깔던 뭐 어쩌던 우분투 17.10 환경에서 IP 설정하는 법을 지금부터 싸지르도록 하겠다.

우분투에서 네트워크 관리가 재밌게 변했는데, 사용자가 netplan을 통해 네트워크를 설정하면, netplan은 우리가 썼던 NetworkManager 에 설정을 자동 적용하여 네트워크를 관리하는 그런 도구다.
이는 영문이지만 우분투 위키 에 소개되어 있다.

이 도구는 설정 파일이 파이썬이나 루비 개발자를 제외한 한국인에게 좀 생소한 형식으로 관리를 하는데, 바로 YAML 형식으로 관리한다는 것이다.
뭐… 우리가 많이 쓰는 텍스트 교환 형식이 XML, JSON, 그리고 자바에서 많이 쓰는 Properties와 행 단위로 설정하는 그런 것들인데…
설명하기 귀찮으니 기냥 위키백과 가서 봐라.

설정 파일은 대충 이렇게 생겼다.

# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
 version: 2
 renderer: networkd
 ethernets:
   ens33:
     dhcp4: yes
     dhcp6: yes

여기서 뭔자 이상한 문자가 있는데, 우분투 17.10부터 이더넷 식별자가 우리가 알던 ethX 방식이 아닌 ensXYZ 방식으로 바뀌었다.
ifconfig 로 볼 수 있으며, 만약 도커 때문에 가려져서 보기 어려우면 ipconfig | grep : 치면 IPv6 항목과 함께 네트워크 식별자들이 나올 것이다.
당연하겠지만 자동 IP 할당이 기본값이다. 이를 담당하는 게 IPv4의 경우 dhcp4, IPv6의 경우 dhcp6 키로 관리한다. 간단하게 쓸거면 yes, 아니면 no로 설정한다.

그렇다면 수동으로 IP를 관리하고자 한다면 어떻게 변경해야 하나?
바로 생소해 보이는 이더넷 식별자 아래 몇가지 사항을 추가하면 된다.
상하위 구분을 공백 수로 구분하기 때문에 공백으로 고생하는 파이썬 개발자들에겐 익숙할 것이다.

# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
 version: 2
 renderer: networkd
 ethernets:
   ens33:
     dhcp4: no
     dhcp6: no
     addresses: [192.168.1.2/24]
     gateway4: 192.168.1.1
     nameservers:
       addresses: [8.8.8.8,8.8.4.4]

여기서 3가지 속성이 추가되는데, addresses, gateway4, nameservers 이다.
뭐 별거 없다. 순서대로 할당할 IP주소, IPv4 방식의 게이트웨이 주소, 그리고 DNS 서버다.
DNS 서버에 하위 항목인 addresses 속성을 추가하여 대괄호로 감싼 쉼표(,) 구분으로 IP를 부여하면 된다.
눈치 깠다면 알겠지만 당연히 IPv6 방식의 게이트웨이 설정은 gateway6이다.
그렇다면 IPv6 방식으로 세팅하려면? 그냥 배열 쳐넣듯이 멀티IP 추가하여 IPv4 IPv6 이렇게 넣는다.
아가리 벌려라 예제 날아온다!

# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
 version: 2
 renderer: networkd
 ethernets:
   ens33:
     dhcp4: no
     dhcp6: no
     addresses: [192.168.1.2/24, '2001:1::2/64']
     gateway4: 192.168.1.1
     nameservers:
       addresses: [8.8.8.8,8.8.4.4]

자 이제 한가지 문제가 남았다. 서브넷 마스크는 어디로 간 것일까?
안타깝게도 서브넷 마스크 속성은 여기에 없다. 하지만, 할당 IP주소 뒤에 붙는 저 익숙치 않은 /24를 주목하자.
아는 사람은 알 것이다. 바로 저건 CIDR, 사이더라고 발음하는 마스킹 넘버다.
위 링크로 들어가면 슬래시 뒤에 들어가는 숫자를 “접두어 합침” 제목 아래 나열되어 있다. 저 숫자에 해당하는 서브넷 마스크를 친절하게 소개하니 참고하여 적용한다.
홈 네트워크나 소규모 네트워크라면 보통 IPv4의 경우 24, IPv6의 경우 64를 쓰면 된다. 끝자리 IP 개수만 할당하는 서브넷 마스크 255.255.255.0 주소와 동일하다.

자, 이제 수정을 했으니 적용해야겠지? 아래 명령어 한번 치면 끝난다.
sudo netplan apply

끝이다. 상당히 간결해졌다.
우부투 위키에서 소개하는 netplan 명령어가 몇가지 있는데, 소개하는 것으로 글을 마치도록 하겠다.

  • netplan generate : 명령어를 실행하면 네트워크 구성에 가장 필수적인 설정 파일을 생성하게 된다. 실수로 네트워크 구성이 망가졌을 경우 쓰면 되겠다.
  • netplan apply : 위에서 소개했듯이 변경한 네트워크 설정을 적용한다. 필요시 재시작할 수 있다.
  • netplan ifupdown-migrate : generate와 동일하긴 한데 /etc/network/interfaces 경로에 있는 네트워크 속성을 netplan 방식으로 마이그레이션 하는 명령어이다.

끗.

참고

composite / 2017년 11월 9일 / Piss Development / 0 Comments

웹 서버와 WAS 서버? 우린 웹으로 무엇을 만들고 있는가?

자바 지배적인 한국에서는 왠만한, 아니, 거의 표준이라고 할 만한 개발용어들 대부분이 자바에서 따왔다.
물론 자바에 없는 개념은 다른 언어에서도 가져오기도 한다.

웹에서는, 자바 경험자들이 IT 관리하다 보니 웹 서비스 시 웹 서버와 WAS 서버라고 칭한다.
웹 서버는 웹 페이지를 서비스하는 서버 프로그램이고. 이에 해당하는 제품이 Apache나 IIS, nginx, webtob 등이 있다.
WAS 서버는 Web Application Server의 약자로, 서버단 언어를 통해 웹 기반의 서비스를 제공하는 서버를 뜻한다. 이에 해당하는 제품이 Tomcat, Jetty, WebLogic, WebSphere, JEUS 등이 있다.

당연히 WAS 단독으로 운영은 가능하며, 자바로 아예 독립적인 웹 서비스를 제공할 수 있다.
하지만 관행적으로 반드시 Tomcat 같은 WAS 서버를 통해서 제공해야 대한민국 개발자들은 직성이 풀린다.

그렇다면 자바로 아예 독립적인 웹 서비스를 제공하는 것을 뭐라고 하느냐.
간단하다. 닷넷에서는 웹 응용 프로그램(Web Application)이라는 용어가 있다.

그렇다. 웹 앱이다. 내가 웹 애비다. 웹 어플리케이션. 웹 프로그램 등등… 그냥 웹 기반의 프로그램인 것이다.
초보들이 어려워하는 이유 안다. 대체적으로 WEB과 WAS 분리 운영, 그리고 서블릿 기반만 가르치다 보니,
자바 혼자서 운영하리라고 생각할 틈을 주지 않는다. PHP는 더하고, 하지만 파이썬이나 루비 등은 오히려 여기에 익숙하다.

갑자기 생각나네. C++ 으로 웹 어플리케이션 제작 후기 올렸는데 왜 생산성 좋은 자바 안쓰냐고 태클건 어느 코더의 댓글…

하지만, 특히 자바 개발자들, 우리는 지금 웹 어플리케이션을 만든다는 것을 잊어선 안 된다.
스프링은 웹 아닌 환경에서도 제공하지만, MVC를 통해 웹 개발 환경도 제공한다.
전자정부는 웹 어플리케이션이라고 칭하지 않는다. 웹 개발 환경이라 칭한다. 왜인진 나도 모른다.
어찌됐던, 우리가 자바던 닷넷이던 그 어떤 언어던 웹 기반의 프로그램을 작성하고 있다면,
웹 앱 또는 웹 응용 프로그램(Web Application)을 개발한다고 해야 모든 언어의 개발자들이 이해하기 쉽다.

이번 글은 웹개발하는 우리의 정체성을 일깨워 주기 위해 싸지른 글이라고 볼 수 있다.
홍콩행 게이바에서 핑크가 딜도 던지는 그런 정체성 말고.

composite / 2017년 10월 24일 / Piss Development / 0 Comments

독립형 OWIN 기반 웹 서버 – NOWIN

보통 닷넷에서 독립형 웹 서비스를 구현할 때 HttpListener 를 쓸 것이다. node.js 처럼 쉽게 구축이 가능하기 때문이다.

물론 그럴 일은 없겠지. 아무래도 안정화된 IIS로 다들 쓸텐데.

그러고 보니 MS도 OWIN 웹 서버인 Katana 를 만들어서 아직까지는 실험적으로 배포하고 있긴 하다. (모노 지원은 개나 줘버리고)

OWIN 표준은 1.0 으로 안정화가 되어 있지만, 이는 기본적인 웹 서비스를 위한 스펙이며, 아직 부가적인 요소 (웹소켓 등)은 표준을 만들고 있는 중이다.

그러는 와중에 드디어 내가 바랬던 프로젝트가 있었으니.. 바로, NOWIN 으로 OWIN 표준 기반 웹 서버다.

https://github.com/Bobris/Nowin

이녀석은 닷넷 4.5로 만든 웹 서버인데, 가장 큰 특징은 HttpListener 를 안썼다는 것이다.

무슨 소리냐고? 지랄같이 제한적인 기본적인 웹 서버 클래스를 안썼다는 것이다.

이말인 즉슨, 직접 웹서버를 닷넷으로 구현했다는 것이다.

이렇게 되면 모노 지원은 이미 따놓은 당상이며, 웹소켓도 아무렇지도 않게 지원된다.

윈도우 7이나 2008 R2 라도, 닷넷 4.5 깔면은 순수 닷넷으로 웹소켓과 웹서버를 한번에 휘어잡을 수 있게 된다.

아파치의 NIO같은 Non-Blocking I/O 를 직접 구현함으로써 극대화한 웹 서버가 이 프로젝트의 특징이다.

아시다시피 네이티브 웹소켓은 윈도우 2012 에 들은 IIS8에 채용되었다.

지금 윈도우 2012 로 닷넷 돌리는 곳이 얼마나 있을까. 가뜩이나 윈도우 라이센스 하면 치가 떨리는데.

프로젝트가 제시한 특징을 알아보자.

  • Http 1.0 와 1.1 클라이언트를 SocketAsyncEventArgs 클래스를 이용하여 가장 빠르게 인터넷을 구현
  • KeepAlive, 비테스트 파이프라인, 요청/응답에 자동 chunked en/decoding 기능 구현
  • 모든 개체에 비동기를 실현하였으며, 자동으로 병렬 코어로 작동하도록 구현
  • SSL 은 .Net SSL 스트림으로 동일한 보안 시스템 구현
  • WebSockets 을 독립적으로 작동할 수 있다! 따라서 SignalR 을 HttpListener 내장된 Win8 보다 더 빠르게 작동시킬 수 있다.
  • 현재 연결 수, 최대 할당 연결, 할당이 필요한 지 추적하는 기능을 제공한다.
  • 연결당 20kb RAM 정도가 소요되며 대부분 재사용된다. 하지만 절대 할당이 해제되지 않는다.
  • 기본적으로 최대 요청/응답 크기는 8KB 이다.
  • Nuget 으로 쉽게 사용이 가능하며, 종속성이 없다.

보아라. 종속성이 없다고 한다. 닷넷의 코어 기능만을 사용하여 웹 서버를 구현한 것이다. 이제 닷넷판 Netty 가 나온 것인가?

그렇다면 사용법을 알아보자.

Microsoft.Owin.Hosting nuget 사용시 샘플

static class Program
{
    static void Main(string[] args)
    {
        var options = new StartOptions
        {
            ServerFactory = "Nowin",
            Port = 8080
        };

        using (WebApp.Start<Startup>(options))
        {
            Console.WriteLine("Running a http server on port 8080");
            Console.ReadKey();
        }
    }
}

public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        app.Use(context =>
        {
            if (context.Request.Path == "/")
            {
                context.Response.ContentType = "text/plain";
                return context.Response.WriteAsync("Hello World!");
            }

            context.Response.StatusCode = 404;
            return Task.Delay(0);
        });
    }
}

빌더를 사용한 Https 샘플

var builder = ServerBuilder.New().SetPort(8888).SetOwinApp(SomeOwinApp);
builder.SetCertificate(new X509Certificate2("certificate.pfx", "password"));
using (builder.Start())
{
    Console.WriteLine("Listening on port 8888. Enter to exit.");
    Console.ReadLine();
}

마치 node.js 의 http API 와 흡사하다. 거기에다가 대리자를 통한 비동기 처리를 구현하였다.

이정도면 원하는 웹 서버를 쓰기 좋지 아니한가? 모노라도?

안타깝게도 아직까지는 안정성과 보안성을 검증하지 못하였다. 계속 테스트 중이며, 아직 실제로 쓰기에 보장이 전혀 없다.

Fork 는 12 지만 실제 참여자는 2명이다. 아는사람인지 알 턱은 없지만.

하지만 그래도 같이 테스트하고 참여해 볼 만 하다. 순수 닷넷으로 이정도를 구현했으면, 자바 부럽지 않은 웹 어플리케이션이 탄생해도 무방하지 아니한가? 이 NOWIN 을 통하여 Nancy 와 SignalR 조합이면 웹 어플리케이션에 두려움은 없을 것이란 생각이 자꾸 든다. 오호.

물론 ASP.NET 기반은 이걸로 동작이 어려울 것이다. ASP.NET MVC 등이 100% OWIN에도 동작하지 않는 이상은.

왜냐면 이들은 HttpListener 기반으로 돌아간다. 호환성은 망했어요.

닷넷에 이 프로젝트는 심히 기대대뇐 프로젝트다. 계속 눈여겨보고 테스트해야겠다.

근데 나 지금 회사에서 자바개발중이라서 아마 안될거야..

집에서 해야겠네.. 흑.

composite / 2014년 1월 8일 / 미분류 / 0 Comments

저도 후기를 올리는군요.

이번에도 기회를 딱 잡았는데 야근덕분에 만져볼 기회가 더욱 없었습니다.

그래도 짬짬이 2012 세팅을 좀 했습니다.

애저 관리 화면은 정말 심플하고 깔끔하다 입니다.

sshot-6.png

가상OS다 보니 이것저것 상태를 한눈에 볼 수 있습니다. 원격에서 문제가 생겼을때 재시작이나 종료가 가능하구요.

처음 사용할때는 뭐가 뭔지 알아내기가 힘들었습니다. 사용자에게 버튼이 어딨는지, 탭이 어딨는지에 의미를 부여했으면 좋겠더군요.

특히 포트를 개방하는 ENDPOINTS 찾느라 해맸습니다…

뭐.. 그렇긴 하지만 역시 가상OS 환경 만지는거는 그냥 하던데로만 하면 되니 얼마나 좋습니까.

저는 2개의 VM에 하나는 웹 서버, 하나는 DB 서버를 사용했습니다.

DB는 MSSQL이 아닌 몽고DB를 깔았습니다.

sshot-3.png

사실.. 웹플랫폼 인스톨러는 어찌보면은 외부툴이라 안정성에 민감한 분이라면 조금 꺼려할 수도 있는 툴입니다.

그만큼 필요한 소프트웨어가 쉽게 깔리다보니요.

만약 웹 서버에서 순수 .NET 환경을 꾸밀거라면 왠만하면 IIS 세팅만 하고 마세요. GAC 줄이는게 웹 프로그램 관리상 이롭습니다.

VS에서 웹개발하고 게시를 하면 독립형 게시를 할 수 있습니다. 서버에 어떤 종속성 필요없이 걍 올리기만 하면 됩니다.

용량을 좀 먹는다는 단점이 있긴 하지만 그렇게 하는 것이 어떤 서버에서도 돌아갈 수 있는 가장 최선의 길이라 생각됩니다.

sshot-5.png

DB 서버에는 몽고디비를 깔고 테스트 좀 해봤습니다. 제가 왜 몽고디비를 깔았냐면은 바로 제가 모델링해서 완성한 주소 줄이는 앱을 올리기 위해서였습니다.

시간만 있었다면 데이터 열나게 올리고 열라게 조회하려고 했지만 시간이 없어서 아쉬움만 남는군요.

거기다가 다음 체험에는 MSSQL 까지 깔아준다 하니..ㅋㅋ

ENDPOINT 로 포트개방을 하였습니다. 아까 관리화면에서 ENDPOINT 글씨 클릭하면 포트 포워딩 비슷한 기능을 할 수 있습니다.

당연히 웹이다 보니 80번 포트를 개방했습니다.

이렇게 세팅한 화면에 제가 만들었던 앱을 올리니 감회가 새롭더군요.

sshot-4.png

감회가 새로울 줄 알았는데 DB 로그인 에러가 먼저 반겨주더군요.. 이상태에서 밤을 보내고 결국 GG치고 말았습니다..

애져를 쓰면서 많은 걸 느꼈습니다.

클라우드의 강점이라 하면은 바로 주문한 대로 준비가 되는 플랫폼 아니겠습니까.

그런 역할을 역시 충실히 해내는 애져입니다.

여러분께서는 이런 클라우드 플랫폼을 어떻게 쓰고 투자하는게 좋겠다 라고 생각하십니까?

저같은 경우에는 글로벌 서비스에 맞는 테스트 및 배포에 용이하다고 생각을 하고 있습니다.

일단 서버가 여러 군데 있으니까요. 한국 서버에서 글로벌하게 서비스 하는건 성능상이나 보안상이나 여러가지 문제점이 있기 때문에 이런 애져를 이용하는 것은 여러분의 서비스에 많은 도움이 되지 않을까 생각됩니다.

따라서 대우형님에게 바라는 것이 있습니다.

– 데스크탑 경험 세팅하지 말아주세요.

– 5차 체험도 만들어주세요. 이번엔 리눅스로!

– 한두개 코어짜리도 체험하게 해주세요. 고사양이면 너무 막쓰게 되잖아요(?)

어쨌든, 클라우드를 몸소 체험하는 좋은 기계 만들어주셔서 감사합니다.

마지막으로 제가 돌리고 있는 2012 서버 스샷 올리고 쿨하게 마치겠습니다.

HP 마이크로서버에 웹서버 깔고 하이퍼브이 깔아도 녀석 튼튼하게 잘돌아갑니다.

mini.png

다음 체험 하면 자바돌려볼까..

composite / 2012년 11월 23일 / 미분류 / 2 Comments