เจาะโครงสร้าง IIS

ความเข้าใจในส่วนนี้เป็นพื้นฐานของการวิเคราะห์ปัญหาในส่วนที่ 09

IIS มักถูกเข้าใจว่าเป็นโปรแกรมเดียว แต่ในทางเทคนิคประกอบด้วยองค์ประกอบสามส่วนที่อยู่คนละระดับของระบบปฏิบัติการ ส่วนหนึ่งทำงานในเคอร์เนลของ Windows ส่วนหนึ่งทำงานเป็น Windows Service และอีกส่วนเป็น process ที่ถูกสร้างและยุติตามปริมาณการใช้งาน

HTTP.sysKERNEL-MODE DRIVER

องค์ประกอบที่ รับฟัง port 80 และ 443 โดยตรง เอกสารของ Microsoft ระบุคุณประโยชน์ไว้สามประการ ได้แก่ การ cache ระดับเคอร์เนล ซึ่งตอบ request ที่ cache ไว้โดยไม่ต้องสลับไปยัง user mode, การจัดคิวระดับเคอร์เนล ซึ่งเก็บ request ไว้จนกว่าจะมี worker process พร้อมรับ และการกรองความปลอดภัยเบื้องต้น

W3SVCWWW PUBLISHING SERVICE

ตั้งแต่ IIS 7 เป็นต้นมา W3SVC ไม่ได้ทำหน้าที่จัดการ worker process อีกต่อไป บทบาทที่คงเหลือคือเป็น listener adapter ของ HTTP.sys ได้แก่ การกำหนดค่าให้ HTTP.sys การปรับปรุงค่าเมื่อ configuration เปลี่ยนแปลง และการแจ้ง WAS เมื่อมี request เข้าสู่คิว

WASWINDOWS PROCESS ACTIVATION SERVICE

องค์ประกอบที่ อ่าน applicationHost.config และบริหารจัดการ Application Pool พร้อมทั้ง worker process เมื่อ pool ใดยังไม่มี worker process WAS จะเป็นผู้เริ่มการทำงานให้ และเมื่อไฟล์ configuration เปลี่ยนแปลง WAS จะได้รับการแจ้งเตือนและปรับปรุงค่าตาม

w3wp.exeWORKER PROCESS

process ที่ประมวลผล request จริง โดยค่าเริ่มต้นมีหนึ่ง process ต่อหนึ่ง Application Pool ภายในประกอบด้วยลำดับของ module ที่ทำงานต่อเนื่องกัน ได้แก่ module static file, module rewrite และ module proxy เป็นต้น

ลำดับการประมวลผล request

ขั้นที่ 2 ถึง 5 เกิดขึ้นเฉพาะกรณีที่ยังไม่มีข้อมูลใน cache หรือ configuration เพิ่งมีการเปลี่ยนแปลง request ในลำดับถัดไปจะเข้าสู่คิวของ worker process ที่ทำงานอยู่แล้วโดยตรง

Site, Application และ Virtual Directory เป็นแกนของ URL ส่วน Application Pool เป็นแกนของ process ทั้งสองแกนเป็นอิสระต่อกัน

ความเข้าใจที่คลาดเคลื่อนที่พบบ่อยที่สุดคือการมองว่า Application Pool อยู่ภายใต้ Site ในความเป็นจริง Site กำหนดว่า URL ใดแมปไปยังไฟล์ใด ขณะที่ Pool กำหนดว่าโค้ดนั้นทำงานใน process ใด และ Application จาก Site ที่ต่างกันสามารถใช้ Pool ร่วมกันได้

Site

หน่วยระดับบนสุด มี binding เป็นของตนเอง และมี physical path เป็นรากของไฟล์

corp-web → D:\apps\corp-web → *:443:app.corp.local

Application

ขอบเขตเชิงตรรกะภายใน site ข้อแตกต่างจากโฟลเดอร์ทั่วไปคือ สามารถกำหนด Application Pool ของตนเองได้

/reports → D:\apps\corp-reports → pool "ReportsPool"

Virtual Directory

การแมป URL ไปยังโฟลเดอร์จริงที่อยู่คนละตำแหน่งหรือคนละไดรฟ์ ต้องอยู่ภายใน Application เสมอ และใช้ pool ของ Application ที่ครอบอยู่

/reports/files → E:\archive

Application Pool

ขอบเขตเชิง process เทียบเท่ากับ w3wp.exe หนึ่ง process แอปพลิเคชันที่อยู่คนละ pool แยกหน่วยความจำและสิทธิ์ออกจากกันโดยสมบูรณ์

เอกสารของ Microsoft ระบุว่า pool ถูกออกแบบมาเพื่อ ป้องกันไม่ให้แอปพลิเคชันหนึ่งส่งผลกระทบต่อแอปพลิเคชันอื่นบนเครื่องเดียวกัน

Binding — องค์ประกอบสามส่วนที่ต้องไม่ซ้ำกัน

Binding กำหนดว่า request ลักษณะใดจะเข้าสู่ site นี้ ประกอบด้วย IP : port : ชื่อโฮสต์ ชุดข้อมูลสามส่วนนี้ต้องไม่ซ้ำกับ site อื่นบนเครื่องเดียวกัน ซึ่งเป็นเหตุผลที่ระบบหลายระบบ สามารถใช้ port 443 ร่วมกันได้ตราบใดที่ชื่อโฮสต์แตกต่างกัน

ลำดับชั้นของไฟล์ configuration

ค่าที่อยู่ในลำดับล่างมีผลเหนือค่าที่อยู่ในลำดับบน ประเด็นสำคัญคือ web.config อยู่ภายใน physical path ของแอปพลิเคชัน จึง ถูกนำติดไปพร้อมกับไฟล์ เมื่อคัดลอกโฟลเดอร์ไปยังเครื่องใหม่ กฎ rewrite จะถูกนำไปด้วยโดยอัตโนมัติ

machine.config                      ระดับ .NET ทั้งเครื่อง
applicationHost.config              ไฟล์หลักของ IIS — WAS อ่านไฟล์นี้
  %windir%\system32\inetsrv\config\
D:\apps\corp-web\web.config         ระดับ site — ตำแหน่งของกฎ rewrite
D:\apps\corp-web\sub\web.config     ระดับโฟลเดอร์ย่อย

ส่งไฟล์จากดิสก์ และส่งต่อ request ไปยัง upstream

เมื่อ request เข้าสู่ w3wp.exe ตามลำดับในส่วนที่ 01 แล้ว IIS จะตัดสินใจอย่างใดอย่างหนึ่งในสองทางนี้เสมอ ทางแรกคือ อ่านไฟล์จากดิสก์แล้วส่งกลับไปโดยตรง ซึ่งใช้กับไฟล์ HTML, JavaScript, CSS และไฟล์ภาพ ทางที่สองคือ ส่ง request ต่อไปยังเซิร์ฟเวอร์อื่นแล้วนำผลลัพธ์กลับมาให้ผู้ใช้ ซึ่งคือการทำ reverse proxy

ตัวที่กำหนดว่าจะเลือกทางใด คือกฎการเขียน URL ที่จะกล่าวถึงในส่วนที่ 06 ผลลัพธ์ที่ได้คือ ทุกองค์ประกอบอยู่ภายใต้โดเมนเดียวกัน ในสายตาของเบราว์เซอร์ จึงไม่จำเป็นต้องกำหนดค่า CORS และ cookie ของการเข้าสู่ระบบทำงานได้ตามปกติ

เหตุผลของการผูก upstream ไว้ที่ loopback

การกำหนดให้ upstream รับฟังเฉพาะ 127.0.0.1 แทน 0.0.0.0 ทำให้ ไม่มีผู้ใดเรียกเข้าไปได้โดยตรงจากเครือข่าย ทุก request ต้องผ่าน IIS ซึ่งเป็นจุดเดียวที่บังคับใช้ TLS ตรวจสอบสิทธิ์ระดับเครือข่าย และบันทึก log ข้อกำหนดนี้เป็นเงื่อนไขจำเป็นของแนวทางในส่วนที่ 07 ด้วย

IIS มาตรฐานไม่รองรับการทำ reverse proxy ต้องติดตั้ง module เพิ่มสองรายการ และลำดับการติดตั้งมีผลต่อการทำงาน

มีค่าหนึ่งที่ต้องปรับจากค่าเริ่มต้นเสมอ

New-Item -ItemType Directory "D:\apps\corp-web" -Force

# คัดลอกไฟล์ static ทั้งชุดมาวางที่ตำแหน่งนี้
# ต้องมี index.html อยู่ที่ราก คือ D:\apps\corp-web\index.html

Import-Module WebAdministration

New-WebAppPool -Name "CorpWebPool"

# กำหนดเป็น No Managed Code — ค่าว่างหมายถึงไม่โหลด .NET runtime
Set-ItemProperty IIS:\AppPools\CorpWebPool -Name managedRuntimeVersion -Value ""

New-Website -Name "corp-web" `
  -PhysicalPath "D:\apps\corp-web" `
  -ApplicationPool "CorpWebPool" `
  -HostHeader "app.corp.local" -Port 80

สิทธิ์การเข้าถึงโฟลเดอร์

โดยค่าเริ่มต้น worker process ของแต่ละ pool ทำงานภายใต้บัญชีเสมือนชื่อ IIS AppPool\<ชื่อ pool> ซึ่งถูกสร้างขึ้นอัตโนมัติพร้อมกับ pool บัญชีนี้ต้องมีสิทธิ์อ่านโฟลเดอร์ที่เก็บไฟล์ static

icacls "D:\apps\corp-web" /grant "IIS AppPool\CorpWebPool":(OI)(CI)RX

หากโฟลเดอร์อยู่ภายใต้ path ที่สืบทอดสิทธิ์มาอย่างครบถ้วนอยู่แล้ว ขั้นตอนนี้อาจไม่จำเป็น ให้ตรวจสอบด้วยการเรียกหน้าเว็บก่อน หากได้รับสถานะ 401 หรือ 403 จึงค่อยกำหนดสิทธิ์เพิ่ม

ลำดับของกฎมีผลต่อการทำงานโดยตรง การสลับลำดับทำให้ระบบทำงานผิดพลาด

จัดวางไฟล์นี้ไว้ที่ D:\apps\corp-web\web.config ซึ่งเป็นรากของ site ตำแหน่งเดียวกับ index.html

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>

        <!-- กฎที่ 1 : ส่ง /api ต่อไปยัง upstream -->
        <rule name="api-to-backend" stopProcessing="true">
          <match url="^api/(.*)" />
          <action type="Rewrite"
                  url="http://127.0.0.1:8080/corp-api/{R:1}" />
        </rule>

        <!-- กฎที่ 2 : path ที่ไม่ใช่ไฟล์จริง ให้ส่ง index.html -->
        <rule name="spa-fallback" stopProcessing="true">
          <match url=".*" />
          <conditions logicalGrouping="MatchAll">
            <add input="{REQUEST_FILENAME}" matchType="IsFile"      negate="true" />
            <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
          </conditions>
          <action type="Rewrite" url="/index.html" />
        </rule>

      </rules>
    </rewrite>
  </system.webServer>
</configuration>

คำอธิบายรายองค์ประกอบ

ชนิดไฟล์ที่ IIS ไม่รู้จัก

IIS ตรวจสอบนามสกุลไฟล์กับรายการ MIME type ที่กำหนดไว้ก่อนส่งออกเสมอ เอกสารของ <mimeMap> ระบุพฤติกรรมนี้ไว้ว่า IIS จะไม่ส่งคืนชนิดไฟล์ที่ไม่ได้เพิ่มไว้ในองค์ประกอบ <staticContent> หรือไม่มี mapping ใน <handlers> และอธิบายว่าเป็นพฤติกรรมที่ออกแบบมาเพื่อป้องกันการเข้าถึงไฟล์ที่ไม่ได้ประกาศไว้ใน configuration

status code ที่ได้รับในกรณีนี้คือ 404.3 ซึ่งเอกสารรายการ status code ของ IIS นิยามไว้ว่า MIME type restriction หมายถึง MIME mapping ปัจจุบันสำหรับนามสกุลที่ร้องขอไม่ถูกต้องหรือยังไม่ได้กำหนดค่า

วิธีแก้คือประกาศนามสกุลนั้นเพิ่มในไฟล์ web.config เดียวกัน เอกสารกำหนดว่าแต่ละรายการต้องประกอบด้วยสองส่วน คือ นามสกุลไฟล์ที่ไม่ซ้ำกันในแอตทริบิวต์ fileExtension และ ชนิดของไฟล์ในแอตทริบิวต์ mimeType ตัวอย่างด้านล่างคัดมาจากเอกสารทางการโดยตรง

<configuration>
  <system.webServer>
    <staticContent>
      <mimeMap fileExtension=".syx" mimeType="application/octet-stream" />
      <mimeMap fileExtension=".tab" mimeType="text/plain" />
    </staticContent>
  </system.webServer>
</configuration>

ให้แทนนามสกุลและชนิดไฟล์ด้วยค่าที่ระบบต้องใช้จริง โดยตรวจสอบก่อนว่านามสกุลใดที่ IIS บนเซิร์ฟเวอร์นั้นยังไม่รู้จัก ซึ่งดูรายการที่มีอยู่ได้จาก IIS Manager ที่รายการ MIME Types ตามขั้นตอนที่เอกสารระบุไว้ แล้วจึงประกาศเฉพาะรายการที่ขาด

เมื่อมี proxy คั่นกลาง upstream จะได้รับ IP ของ IIS แทน IP ของผู้ใช้

ประเด็นนี้เป็นผลสืบเนื่องที่เกิดขึ้นกับสถาปัตยกรรม reverse proxy ทุกรูปแบบ และส่งผลกระทบต่อสองเรื่องที่มักพบเมื่อระบบเริ่มใช้งานจริง ได้แก่ การบันทึก IP ที่คลาดเคลื่อนใน log ของ upstream และลิงก์ที่เซิร์ฟเวอร์นั้นสร้างขึ้นเองซึ่งชี้กลับไปยังชื่อโฮสต์ภายใน

หมายเลข IP ของผู้ใช้

เมื่อ IIS ส่ง request ต่อไปยัง upstream การเชื่อมต่อในช่วงนั้นเกิดจาก IIS เอง upstream จึงเห็น IP ต้นทางเป็นของ IIS ไม่ใช่ของผู้ใช้ ข้อมูล IP เดิมจะเดินทางต่อไปได้ก็ต่อเมื่อถูกใส่ไว้ใน header

header ที่ IIS ใช้กับข้อมูลนี้คือ X-Forwarded-For ซึ่งยืนยันได้จากรายการ status code ของ IIS ที่กำหนดรหัสย่อย 400.10 ไว้ตั้งแต่ IIS 8.0 โดยมีนิยามว่า Invalid X-Forwarded-For (XFF) header กล่าวคือ IIS ตรวจสอบความถูกต้องของ header นี้และปฏิเสธ request เมื่อค่าไม่ถูกต้อง

ก่อนนำไปใช้จริง ให้ทดสอบด้วยการอ่าน header ที่ upstream ได้รับจริงหนึ่งครั้ง เพื่อยืนยันว่ามีค่านี้เดินทางมาถึงและอยู่ในรูปแบบที่แอปพลิเคชันอ่านได้

ชื่อโฮสต์เดิม

ค่า preserveHostHeader ทำให้ request ที่ส่งต่อไปยัง upstream มี header Host เช่นเดียวกับที่ได้รับเข้ามาที่ IIS แทนที่จะเป็นค่าที่ถูกแก้ไขเพื่อการ routing ของ ARR เอกสารกรณีศึกษาการใช้ ARR ของ Microsoft ระบุเหตุผลของการตั้งค่านี้เป็น true ไว้ตรงกันว่า แอปพลิเคชันจำเป็นต้องเห็น host header เดิมบน request ที่ถูก proxy มา ซึ่งจำเป็นเมื่อ upstream สร้าง absolute URL จากค่า Host ที่ได้รับ

เอกสารฉบับเดียวกันแสดงให้เห็นว่าค่าในกลุ่มนี้อยู่ในองค์ประกอบ <proxy> ของไฟล์ applicationHost.config ซึ่งเป็นระดับเซิร์ฟเวอร์ ไม่ใช่ระดับ site

การส่งผลการยืนยันตัวตนของ Windows

กรณีที่องค์กรต้องการให้ IIS เป็นผู้ยืนยันตัวตนกับ Active Directory แล้วส่งผลการตรวจสอบต่อไปให้ upstream จะต้องเปิดใช้งาน Windows Authentication เอกสารของ <windowsAuthentication> ระบุว่า การติดตั้ง IIS ตามค่าเริ่มต้นไม่มี role service นี้มาด้วย และกำหนดลำดับการดำเนินการไว้สามขั้นตามนี้

1. ติดตั้ง role service ชื่อ Windows Authentication ผ่าน Server Manager ที่ Web Server (IIS) → Web Server → Security → Windows Authentication
2. ปิด Anonymous authentication ของ site หรือ application นั้น
3. เปิด Windows authentication ของ site หรือ application นั้น

หลังติดตั้ง role service แล้ว IIS จะเขียนค่า <windowsAuthentication enabled="false" /> ลงใน ApplicationHost.config กล่าวคือ ค่าเริ่มต้นของแอตทริบิวต์ enabled คือ false จึงต้องเปิดเองเสมอ

appcmd.exe set config "corp-web" ^
  -section:system.webServer/security/authentication/anonymousAuthentication ^
  /enabled:"False" /commit:apphost

appcmd.exe set config "corp-web" ^
  -section:system.webServer/security/authentication/windowsAuthentication ^
  /enabled:"True" /commit:apphost

เมื่อเปิดค่านี้แล้ว IIS จะเป็นผู้จัดการการยืนยันตัวตนทั้งหมด และ upstream จะได้รับเฉพาะ request ที่ผ่านการตรวจสอบแล้ว ส่วนการส่งชื่อผู้ใช้ต่อไปให้เซิร์ฟเวอร์นั้น ต้องกำหนดเป็น header เพิ่มเติม ซึ่งอยู่ภายใต้ข้อกำหนดด้านความปลอดภัยข้างต้นทุกประการ

TLS สิ้นสุดที่ชั้น IIS ส่วนการสื่อสารภายในเป็น HTTP ธรรมดาบน loopback

ในสถาปัตยกรรมนี้ IIS เป็นจุดเดียวที่รับ TLS ขณะที่ช่วงระหว่าง IIS กับ upstream สื่อสารผ่าน 127.0.0.1 ซึ่งไม่ออกจากเครื่อง จึงไม่จำเป็นต้องทำ TLS ซ้ำอีกชั้น

# แสดงใบรับรองที่ติดตั้งอยู่ในเครื่อง และบันทึก Thumbprint ของใบที่จะใช้งาน
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, Thumbprint, NotAfter

# ผูก binding แบบ https เข้ากับ site
New-WebBinding -Name "corp-web" -Protocol https -Port 443 `
  -HostHeader "app.corp.local" -SslFlags 1

ค่า -SslFlags ระบุชนิดของใบรับรองและที่เก็บ เอกสารของ cmdlet กำหนดค่าไว้สี่ค่า คือ 0 ใบรับรองปกติใน Windows certificate storage · 1 ใบรับรองแบบ SNI · 2 central certificate store · 3 SNI ใน central certificate store ค่า 1 จึงเป็นการเปิดใช้งาน SNI ซึ่งทำให้ site หลายรายการ ใช้ใบรับรองต่างกันบน port 443 เดียวกันได้ ตามหลักการ binding ในส่วนที่ 02

# "my" คือชื่อ store ซึ่งตรงกับ Cert:\LocalMachine\My
(Get-WebBinding -Name "corp-web" -Port 443 -Protocol "https").AddSslCertificate(
  "a909502dd82ae41433e6f83886b00d4277a32a7b", "my")

แทนที่สตริง Thumbprint ด้วยค่าจริงของใบรับรองที่องค์กรใช้ ค่าที่แสดงไว้เป็นตัวอย่างจากเอกสารของ Microsoft

การบังคับใช้ HTTPS

เพิ่มกฎต่อไปนี้เป็นกฎลำดับแรกสุด ภายใน <rules> ของไฟล์ web.config โดยอยู่ก่อนกฎทั้งสองข้อในส่วนที่ 06

<rule name="force-https" stopProcessing="true">
  <match url="(.*)" />
  <conditions>
    <add input="{HTTPS}" pattern="^OFF$" />
  </conditions>
  <action type="Redirect" url="https://{HTTP_HOST}/{R:1}"
          redirectType="Permanent" />
</rule>

กรณีนี้ใช้ Redirect แทน Rewrite เนื่องจากมีเจตนาให้เบราว์เซอร์ เปลี่ยน URL บนแถบที่อยู่จริง ซึ่งตรงข้ามกับกรณีของ /api ในส่วนที่ 06 ที่ต้องการปกปิดโครงสร้างภายในจากผู้ใช้

ระบุ log ที่ถูกต้องก่อน แล้วจึงวิเคราะห์สาเหตุ

ตามรูปที่ 1 request เดินทางผ่านหลายชั้น และ แต่ละชั้นบันทึกข้อมูลลงคนละไฟล์ การเปิด log ที่ไม่ตรงกับชั้นที่เกิดปัญหา เป็นสาเหตุที่ทำให้เข้าใจว่าระบบไม่ได้บันทึกข้อมูลใดไว้

อาการที่พบบ่อยและจุดที่ควรตรวจสอบก่อน

การเปิด Failed Request Tracing

เมื่อ log ปกติยังไม่เพียงพอ IIS มีเครื่องมือที่บันทึกรายละเอียดของ request ที่ล้มเหลวเป็นรายครั้ง เอกสารของ Microsoft อธิบายหลักการทำงานไว้ว่า เครื่องมือนี้เก็บ trace event ของ request ไว้ในบัฟเฟอร์ และเขียนลงดิสก์เฉพาะเมื่อ request นั้นล้มเหลว โดยผู้ดูแลเป็นผู้กำหนดเองว่าอะไรนับเป็นความล้มเหลว จึงเป็นวิธีที่ตรงที่สุดในการหาสาเหตุของ 404.3 และปัญหาที่เกิดจากกฎ rewrite

ส่วนประกอบที่ต้องติดตั้งคือ Tracing ซึ่งอยู่ใต้ World Wide Web Services → Health and Diagnostics → Tracing ตามที่เอกสารระบุ จากนั้นเปิดใช้งานที่ระดับ site ผ่าน IIS Manager โดยเลือก site แล้วเลือก Failed Request Tracing ในบานหน้าต่าง Actions และเพิ่มกฎที่ Failed Request Tracing Rules พร้อมระบุ status code ที่ต้องการติดตาม

<location path="corp-web">
  <system.webServer>
    <tracing>
      <traceFailedRequests>
        <add path="*">
          <traceAreas>
            <add provider="WWW Server" areas="Security" verbosity="Verbose" />
          </traceAreas>
          <failureDefinitions statusCodes="404.3" />
        </add>
      </traceFailedRequests>
    </tracing>
  </system.webServer>
</location>

ไฟล์ผลลัพธ์ถูกเก็บไว้ที่ %SystemDrive%\inetpub\logs\FailedReqLogFiles\W3SVC<หมายเลข site> โดยเขียน หนึ่งไฟล์ต่อหนึ่ง request ที่ล้มเหลว เช่น fr000001.xml พร้อมไฟล์ freb.xsl หนึ่งไฟล์ต่อหนึ่งโฟลเดอร์สำหรับใช้เปิดดูผลลัพธ์

งานฝั่งแอปพลิเคชันที่ต้องสอดคล้องกับการตั้งค่า IIS ในส่วนก่อนหน้า

ส่วนที่ 01 ถึง 09 อธิบายเฉพาะชั้น IIS โดยเรียกปลายทางว่า upstream เพื่อให้ใช้ได้กับทุกเทคโนโลยี ส่วนนี้ลงรายละเอียดเฉพาะกรณีที่ปลายทางคือ Spring Boot ที่ทำงานบน Apache Tomcat โดยจำกัดเฉพาะจุดที่ต้องตั้งค่าให้สอดคล้องกับ IIS เท่านั้น มิได้ครอบคลุมการพัฒนาแอปพลิเคชัน

ขอบเขตที่ IIS ไม่เกี่ยวข้อง

ประเด็นที่ต้องเข้าใจก่อนคือ w3wp.exe ไม่ได้ประมวลผลโค้ด Java เลย JVM ที่รัน Spring Boot อยู่ใน process ของ Tomcat ซึ่งแยกจากกันโดยสิ้นเชิง IIS เพียงเปิดการเชื่อมต่อ HTTP ไปยัง port ที่ Tomcat รับฟัง แล้วส่งผลลัพธ์กลับมาให้ผู้ใช้ ตามที่อธิบายไว้ในส่วนที่ 03

ส่งมอบเป็น WAR ไม่ใช่ JAR

โดยค่าเริ่มต้น Spring Boot สร้างไฟล์ JAR ที่มี Tomcat ฝังอยู่ภายในและรันตัวเองได้ แต่เมื่อปลายทางคือ Tomcat ที่ติดตั้งแยกบนเครื่อง สิ่งที่ต้องส่งมอบคือไฟล์ WAR เอกสารของ Spring Boot กำหนดขั้นตอนการแปลงไว้ดังนี้

@SpringBootApplication
public class MyApplication extends SpringBootServletInitializer {

  @Override
  protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
    return application.sources(MyApplication.class);
  }

  public static void main(String[] args) {
    SpringApplication.run(MyApplication.class, args);
  }

}

<packaging>war</packaging>

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-tomcat</artifactId>
  <scope>provided</scope>
</dependency>

context path มาจากชื่อไฟล์ WAR

ค่า /corp-api ที่ปรากฏในกฎ rewrite ของส่วนที่ 06 ไม่ได้ตั้งขึ้นลอย ๆ แต่ถูกกำหนดโดย ชื่อไฟล์ WAR ที่วางไว้ใน Tomcat เอกสารของ Tomcat ระบุกฎการตั้งชื่อไว้ว่า หาก context path เป็นสตริงว่าง ชื่อฐานของไฟล์จะเป็น ROOT ซึ่งเป็นตัวพิมพ์ใหญ่เสมอ กรณีอื่นชื่อฐานคือ context path ที่ตัดเครื่องหมาย / นำหน้าออก แล้วแทนที่ / ที่เหลือด้วย #

ตามตัวอย่างในเอกสาร ยังมีรูปแบบระบุเวอร์ชันด้วย ## เช่น foo##42.war สำหรับ context path /foo เวอร์ชัน 42

จำกัดการรับฟังของ Tomcat

ส่วนที่ 03 และ 07 ตั้งอยู่บนเงื่อนไขว่า upstream เข้าถึงได้จาก IIS เท่านั้น เอกสารของ HTTP Connector ระบุว่าแอตทริบิวต์ address ใช้กำหนดว่าจะรับฟังที่ที่อยู่ใด และ โดยค่าเริ่มต้น connector จะรับฟังทุกที่อยู่ในเครื่อง การจำกัดขอบเขตจึงต้องระบุแอตทริบิวต์นี้เอง

<Connector port="8080" protocol="HTTP/1.1"
           address="127.0.0.1" />

เอกสารอธิบายเฉพาะหน้าที่ของแอตทริบิวต์นี้ ไม่ได้ยกตัวอย่างการใช้ 127.0.0.1 เพื่อความปลอดภัยไว้โดยตรง ค่าดังกล่าวจึงเป็นการนำแอตทริบิวต์ มาใช้ให้ตรงกับข้อกำหนดด้านความปลอดภัยในส่วนที่ 07 ของเอกสารฉบับนี้

การรับค่า header ที่ IIS ส่งมา

ส่วนที่ 07 อธิบายว่า IIS ส่งข้อมูล client ต่อมาในรูป header ฝั่ง Spring Boot ต้องถูกกำหนดค่าให้นำ header เหล่านั้นมาใช้ด้วย มิฉะนั้นจะถูกละเลย เอกสารระบุ property ชื่อ server.forward-headers-strategy ซึ่งรับค่าได้สามแบบ

server.forward-headers-strategy=NATIVE

สรุปค่าที่ต้องตรงกันทั้งสองฝั่ง

หากค่าใดค่าหนึ่งในตารางไม่ตรงกัน อาการที่พบจะตรงกับรายการในตารางวิเคราะห์ปัญหาของส่วนที่ 09

upstream คืออะไร และตอนพัฒนาต่างจากตอนใช้งานจริงอย่างไร

ตลอดส่วนที่ 01 ถึง 09 เราเรียกปลายทางว่า upstream โดยไม่ระบุว่าเป็นอะไร ส่วนนี้อธิบายว่าเมื่อปลายทางคือ Tomcat แล้วมันคืออะไร ทำงานอย่างไร และเหตุใดสภาพแวดล้อมตอนพัฒนาจึงต่างจากตอนใช้งานจริง

Tomcat คืออะไร

เอกสารของ Apache นิยาม Tomcat ว่าเป็น ซอฟต์แวร์โอเพนซอร์สที่ implement เทคโนโลยี Jakarta EE บางส่วน พูดให้ตรงกับบริบทของเอกสารฉบับนี้คือ มันทำหน้าที่แบบเดียวกับ IIS แต่สำหรับโค้ด Java

ทำไมต้องเป็นเวอร์ชัน 11

ความต่างระหว่างเวอร์ชันไม่ใช่แค่ความใหม่ แต่คือ สเปกที่ implement และ เวอร์ชัน Java ขั้นต่ำ ซึ่งเป็นข้อจำกัดแบบตายตัว

เอกสารระบุว่า Tomcat 11.0.x เป็นสายที่อยู่ระหว่างการพัฒนาหลักในปัจจุบัน พัฒนาต่อจาก 10.1.x และ implement Servlet 6.1 · JSP 4.0 · EL 6.0 · WebSocket 2.2 · Authentication 3.1 ซึ่งเป็นชุดที่แพลตฟอร์ม Jakarta EE 11 กำหนด

การนำ WAR ขึ้นเซิร์ฟเวอร์

เอกสารของ Tomcat ระบุว่า เมื่อแอตทริบิวต์ autoDeploy ของ Host เป็น true — ซึ่งเป็นค่าเริ่มต้น — Host จะพยายาม deploy และปรับปรุงแอปพลิเคชันให้เองแบบพลวัต เช่นเมื่อมีไฟล์ .WAR ใหม่ถูกวางลงใน appBase ครอบคลุมทั้งการ deploy ครั้งแรกและการ deploy ซ้ำของแอปที่เคยติดตั้งแล้ว

หมายความว่าการนำขึ้นระบบในกรณีปกติคือ คัดลอกไฟล์ .war ลงใน webapps โดยไม่ต้องรีสตาร์ท Tomcat ต่างจากฝั่ง IIS ที่การเปลี่ยน web.config มีผลทันทีเช่นกัน ทั้งสองฝั่งจึงไม่ต้องหยุดบริการเพื่ออัปเดตตามปกติ

การทำให้ Tomcat ทำงานเป็น Windows Service

เพื่อให้ Tomcat เริ่มทำงานเองเมื่อเปิดเครื่อง ต้องติดตั้งเป็น service เอกสารระบุว่าใช้สคริปต์ service.bat และ ต้องมีสิทธิ์ระดับ Administrator จึงจะรันสคริปต์นี้ได้

service.bat install

:: หรือระบุชื่อ service เองได้
service.bat install MyService

เอกสารระบุว่า Tomcat11w เป็นโปรแกรมแบบกราฟิกสำหรับ เฝ้าดูและกำหนดค่า Tomcat service · ส่วนไฟล์ catalina.out จะรับทุกอย่างที่ถูกเขียนลง System.out และ System.err ซึ่งรวมถึง exception ที่ไม่ถูกดักจับ จึงเป็นไฟล์แรกที่ควรเปิดดูเมื่อแอปไม่ทำงาน ตามตารางในส่วนที่ 09

เหตุผลที่แยก frontend กับ backend ตอนพัฒนา

บนเครื่องของผู้พัฒนา ทั้งสองฝั่งรันเป็นคนละ process และคนละ port เอกสารของ Vite ระบุว่า port เริ่มต้นของ dev server คือ 5173 และหาก port นั้นถูกใช้อยู่แล้ว Vite จะลองหา port ว่างถัดไปให้เอง ส่วนฝั่ง Spring Boot รันแยกต่างหากที่ port ของตัวเอง

การแยกเช่นนี้ทำให้แต่ละฝั่ง รีโหลดตัวเองได้โดยไม่กระทบอีกฝั่ง ฝั่ง frontend เห็นผลทันทีเมื่อแก้ไฟล์ ส่วนฝั่ง backend เอกสาร Spring Boot ระบุว่าแอปที่ใช้ spring-boot-devtools จะรีสตาร์ทอัตโนมัติเมื่อไฟล์บน classpath เปลี่ยนแปลง ซึ่งเอกสารอธิบายว่าเป็นประโยชน์เมื่อทำงานใน IDE เพราะได้ผลตอบกลับที่รวดเร็วมาก

ผลลัพธ์ของการ build และค่าที่ต้องตรงกับการตั้งค่า IIS

ส่วนนี้จำกัดเฉพาะจุดที่ frontend มาบรรจบกับ IIS คือ ไฟล์ที่ได้จากการ build วางอย่างไร และ ค่าใดต้องตรงกับกฎที่ตั้งไว้ในส่วนที่ 06 มิได้ครอบคลุมการเขียนคอมโพเนนต์หรือการออกแบบหน้าจอ

ผลลัพธ์ของการ build คือไฟล์ static ล้วน

เอกสารของ Vite ระบุว่าเมื่อสั่ง npm run build ผลลัพธ์จะถูกวางไว้ที่โฟลเดอร์ dist โดยค่าเริ่มต้น และสามารถนำโฟลเดอร์นี้ไป deploy บนแพลตฟอร์มใดก็ได้ เนื้อหาภายในประกอบด้วยไฟล์ HTML หนึ่งไฟล์ กับไฟล์ JavaScript และ CSS ที่เอกสารเรียกว่า hashed assets

ก่อนนำขึ้นเซิร์ฟเวอร์ สามารถทดสอบผลลัพธ์ในเครื่องได้ด้วย npm run preview ซึ่งเอกสารระบุว่าจะเปิดเว็บเซิร์ฟเวอร์แบบ static ในเครื่องเพื่อเสิร์ฟไฟล์จาก dist ขั้นนี้ช่วยแยกได้ว่าปัญหาเกิดจากตัวไฟล์เองหรือเกิดจากการตั้งค่า IIS

เหตุผลที่ต้องมีกฎ fallback ใน web.config

กฎ spa-fallback ในส่วนที่ 06 ไม่ใช่เทคนิคเฉพาะของ IIS แต่เป็นข้อกำหนดของแอปพลิเคชันแบบหน้าเดียวทุกตัว เอกสารของ React Router ระบุไว้ว่า เป็นเรื่องปกติของการ deploy SPA ทุกแบบที่ต้องกำหนดค่าให้โฮสต์ ส่งทุก URL ไปยัง index.html ของผลลัพธ์ฝั่ง client พร้อมระบุว่าโฮสต์บางรายทำให้โดยค่าเริ่มต้น แต่บางรายไม่ทำ

หากใช้ React Router ในโหมด framework ที่เปิด SPA Mode เอกสารระบุว่าให้ deploy โฟลเดอร์ build/client แทน ชื่อโฟลเดอร์จึงขึ้นกับเครื่องมือที่ใช้ ให้ตรวจจากผลลัพธ์จริงก่อนคัดลอกขึ้นเซิร์ฟเวอร์

base path ต้องตรงกับตำแหน่งที่วาง

ลิงก์ของไฟล์ JavaScript และ CSS ที่ปรากฏใน index.html ถูกกำหนดตั้งแต่ขั้นตอน build ไม่ใช่ตอนเรียกใช้งาน เอกสารของ Vite อธิบายค่า base ไว้ว่าเป็น public base path ที่ใช้ทั้งตอนพัฒนาและตอน production โดยรับค่าเป็น absolute URL pathname เช่น /foo/ · URL เต็ม · หรือสตริงว่างกับ ./ สำหรับการฝังไว้ในระบบอื่น

เอกสารระบุเพิ่มว่า หากนำโปรเจกต์ไป deploy ใต้ path ย่อย เพียงกำหนดค่า base แล้ว path ของ asset ทั้งหมดจะถูกเขียนใหม่ให้เอง ครอบคลุมทั้ง URL ของ asset ที่ import ผ่าน JavaScript, การอ้างอิงด้วย url() ใน CSS และการอ้างอิง asset ในไฟล์ HTML

vite build --base=/my/public/path/

วิธีนำไฟล์ขึ้นเซิร์ฟเวอร์

เอกสารของ Vite เรียกไฟล์ผลลัพธ์ว่า hashed assets กล่าวคือชื่อไฟล์ผูกกับเนื้อหา จึงเปลี่ยนไปทุกครั้งที่ build ใหม่ คุณสมบัตินี้มีผลโดยตรงต่อวิธีคัดลอกไฟล์ขึ้นเซิร์ฟเวอร์

proxy ตอนพัฒนา ไม่ใช่ตัวเดียวกับ IIS

บนเครื่องของผู้พัฒนาไม่มี IIS คอยส่งต่อ /api ให้ เครื่องมือพัฒนาจึงมีกลไกของตัวเองมาแทน เอกสารของ Vite ระบุว่าค่า server.proxy ใช้ กำหนดกฎ proxy สำหรับ dev server โดยคำขอที่ path ขึ้นต้นด้วยคีย์ที่ระบุจะถูกส่งต่อไปยังปลายทางที่กำหนด

สรุปค่าที่ต้องตรงกันทั้งสองฝั่ง

ร้อยทุกส่วนที่ผ่านมาเข้าด้วยกัน — React, IIS, Tomcat และ Spring Boot ในเส้นทางเดียว

ส่วนที่ 01 ถึง 12 อธิบายแต่ละชิ้นแยกกันว่าคืออะไรและตั้งค่าอย่างไร ส่วนนี้นำทั้งหมดมาประกอบเป็นภาพเดียว เพื่อตอบสามคำถามที่เหลือ คือ สถาปัตยกรรมแบบนี้เรียกว่าอะไร · ทำไมถึงเลือกแบบนี้ · และค่าใดบ้างที่ต้องตรงกันตลอดเส้นทาง

สถาปัตยกรรมแบบนี้เรียกว่าอะไร

รูปแบบที่เราใช้มีชื่อเรียกอยู่แล้ว การรู้ชื่อมีประโยชน์เวลาค้นหาข้อมูลเพิ่มเติม หรือคุยกับคนนอกทีม เพราะคำเหล่านี้เป็นคำที่ใช้กันทั่วไปในวงการ

Decoupled architectureบางที่เรียก HEADLESS

การแยก frontend กับ backend ออกเป็นคนละโปรเจกต์ที่ build และ deploy แยกกัน โดยสื่อสารกันผ่าน HTTP เท่านั้น ทั้งสองฝั่งไม่รู้จักโค้ดของกันและกันเลย รู้เพียงว่าต้องเรียก URL ไหนและจะได้ข้อมูลรูปแบบใดกลับมา

Client-side renderingCSR

หน้าจอถูกประกอบขึ้นในเบราว์เซอร์ของผู้ใช้ ไม่ได้ประกอบมาจากเซิร์ฟเวอร์ สิ่งที่เซิร์ฟเวอร์ส่งไปคือไฟล์ JavaScript กับ HTML เปล่า ๆ หนึ่งไฟล์ ตามที่อธิบายไว้ในส่วนที่ 12

Reverse proxyIIS ทำหน้าที่นี้

ตัวกลางที่รับ request แทนเซิร์ฟเวอร์จริง แล้วส่งต่อให้เบื้องหลัง ผู้ใช้เห็นแค่ปลายทางเดียวคือ IIS ไม่รู้ว่าข้างหลังมีอะไรอยู่กี่ตัว

Same-origin deploymentผลที่ได้

เมื่อทั้งไฟล์หน้าเว็บและ API อยู่ใต้โดเมนเดียวกัน เบราว์เซอร์ถือว่าเป็นต้นทางเดียวกัน จึงไม่ต้องตั้งค่า CORS และ cookie ทำงานได้ตามปกติ ซึ่งเป็นเหตุผลสำคัญข้อหนึ่งที่วาง IIS ไว้ด้านหน้า

ทำไมถึงเลือกแบบนี้

ทางเลือกอื่นมีอยู่ และไม่ได้แย่กว่าเสมอไป แต่ในเงื่อนไขของงานนี้ Decoupled ได้เปรียบ ด้วยเหตุผลสี่ข้อ

เส้นทางของ request ตามลำดับเวลา

แผนภาพด้านล่างอ่านจากซ้ายไปขวาตามเวลา แต่ละแถวคือผู้เล่นหนึ่งราย ตัวเลขคือลำดับเหตุการณ์ สังเกตความต่างของสองช่วง — ช่วงโหลดหน้าเว็บจบที่ IIS ไม่ลงไปถึง Tomcat เลย

ใครรับผิดชอบช่วงไหน

เส้นทางของ request สองแบบ

ทุก request ที่เข้ามาจะเดินตามหนึ่งในสองเส้นทางนี้เสมอ ตัวที่ตัดสินคือกฎใน web.config ตามส่วนที่ 06

ค่าที่ต้องตรงกันตลอดเส้นทาง

นี่คือรายการที่รวบรวมจากทุกส่วน หากค่าใดไม่ตรงกัน อาการที่พบจะตรงกับตารางในส่วนที่ 09

คำที่ปรากฏตลอดเอกสาร รวบรวมไว้ที่เดียวเพื่อใช้เปิดย้อนดูระหว่างอ่าน

คอลัมน์สุดท้ายบอกว่าคำนั้นถูกอธิบายอย่างละเอียดอยู่ในส่วนใด หากเจอคำที่ไม่คุ้นระหว่างอ่าน ให้กลับมาดูที่นี่ก่อน

องค์ประกอบของ IIS

module และการส่งต่อ

ฝั่ง Java และ Tomcat

ฝั่ง frontend และสถาปัตยกรรม

ทุกสิ่งที่เอกสารนี้พูดถึง วางเป็น node เดียวกันทั้งฉบับ แล้วโยงด้วยความสัมพันธ์ที่มีชื่อ

เอกสารแบ่งเป็น 13 ส่วน แต่ละส่วนอธิบายคนละเรื่อง ผลข้างเคียงคือผู้อ่านเห็นทีละส่วน แล้วไม่เห็นว่า context path ในส่วนที่ 11 เป็นค่าเดียวกับที่กฎ rewrite ในส่วนที่ 06 ต้องชี้ไปหา หน้านี้จึงถอดเนื้อหาทั้งฉบับออกมาเป็นกราฟ node คือสิ่งที่เอกสารพูดถึง เส้นคือความสัมพันธ์ที่มีชื่อกำกับ

วิธีที่ทำให้ข้อมูลถึงกันหมด

คำถามว่า “ทำอย่างไรให้ข้อมูลถึงกันหมด” มีคำตอบเป็นกฎที่เขียนไว้ในมาตรฐานจริง ไม่ใช่การลากเส้นให้มากที่สุด ห้าข้อด้านล่างคือกฎที่กราฟนี้ยึดและตรวจตามได้

subject        predicate      object
WAR            DEPLOYED_TO    webapps
Tomcat 11      SCANS          webapps
                              ^^^^^^^ resource เดียวกัน

เดินกราฟ : WAR → webapps → Tomcat 11    path length = 2

node กับ relationship ต่างกันอย่างไร

นิยามที่ใช้ในหน้านี้มาจากเอกสาร property graph ของ Neo4j ซึ่งเป็นรูปแบบเดียวกับที่ graph database ใช้จริง

รายการ relationship ทั้งหมด

ตารางนี้คือกราฟเดียวกับภาพด้านบน เขียนในรูป triple ทุกแถวคือหนึ่งเส้น ค้นคำใน predicate เพื่อหาความสัมพันธ์ชนิดเดียวกันได้ทั้งหมด

การตรวจสอบกราฟนี้

ทุกบรรทัดในตารางนี้ได้จากการรันสคริปต์กับข้อมูลกราฟจริง มิใช่การประเมินด้วยสายตา