วิธีการปรับใช้แอปพลิเคชัน ASP.NET โดยไม่มีเวลาหยุดทำงาน

ในการปรับใช้เว็บไซต์เวอร์ชันใหม่เราดำเนินการดังต่อไปนี้:

1. บีบรหัสใหม่แล้วอัปโหลดไปยังเซิร์ฟเวอร์
2. บนเซิร์ฟเวอร์สดลบโค้ดสดทั้งหมดออกจากไดเร็กทอรีเว็บไซต์ IIS
3. แตกไฟล์ zip รหัสใหม่ลงในไดเร็กทอรี IIS ที่ว่างเปล่าในขณะนี้

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

ข้อเสนอแนะเกี่ยวกับวิธีการหยุดทำงาน 0 วินาทีหรือไม่?

คุณต้องมีเซิร์ฟเวอร์ 2 เครื่องและตัวโหลดบาลานเซอร์ นี่คือขั้นตอน:

1. เปิดการรับส่งข้อมูลทั้งหมดบนเซิร์ฟเวอร์ 2
2. ปรับใช้บนเซิร์ฟเวอร์ 1
3. ทดสอบเซิร์ฟเวอร์ 1
4. เปิดการรับส่งข้อมูลทั้งหมดบนเซิร์ฟเวอร์ 1
5. ปรับใช้บนเซิร์ฟเวอร์ 2
6. ทดสอบเซิร์ฟเวอร์ 2
7. เปิดการรับส่งข้อมูลบนเซิร์ฟเวอร์ทั้งสองเครื่อง

แม้ว่าในกรณีนี้คุณจะยังคงมีการรีสตาร์ทแอปพลิเคชันและการสูญเสียเซสชันหากคุณใช้ "เซสชันติดหนึบ" หากคุณมีเซสชันฐานข้อมูลหรือเซิร์ฟเวอร์สถานะทุกอย่างก็น่าจะดี

เครื่องมือการปรับใช้เว็บของ Microsoftสนับสนุนนี้ในระดับหนึ่ง:

เปิดใช้งานการสนับสนุน Windows Transactional File System (TxF) เมื่อเปิดใช้งานการสนับสนุน TxF การทำงานของไฟล์จะเป็นแบบปรมาณู นั่นคือพวกเขาประสบความสำเร็จหรือล้มเหลวโดยสิ้นเชิง สิ่งนี้ทำให้มั่นใจได้ถึงความสมบูรณ์ของข้อมูลและป้องกันไม่ให้ข้อมูลหรือไฟล์ที่มีอยู่ในสถานะ "ครึ่งทาง" หรือเสียหาย ใน MS Deploy TxF ถูกปิดใช้งานโดยค่าเริ่มต้น

ดูเหมือนว่าธุรกรรมนี้มีไว้สำหรับการซิงค์ทั้งหมด นอกจากนี้ TxF ยังเป็นคุณลักษณะของ Windows Server 2008 ดังนั้นคุณลักษณะธุรกรรมนี้จะไม่ทำงานกับเวอร์ชันก่อนหน้านี้

ฉันเชื่อว่าเป็นไปได้ที่จะแก้ไขสคริปต์ของคุณสำหรับ 0-downtime โดยใช้โฟลเดอร์เป็นเวอร์ชันและ IIS metabase:

• สำหรับเส้นทาง / url ที่มีอยู่:
  • เส้นทาง : \ web \ app \ v2.0 \
  • url : http: // app
• คัดลอกเว็บไซต์ใหม่ (หรือแก้ไข) ไปยังเซิร์ฟเวอร์ภายใต้
  • \ เว็บ \ แอป \ v2.1 \
• แก้ไข IIS metabase เพื่อเปลี่ยนเส้นทางเว็บไซต์
  • จาก \ web \ app \ 2.0 \
  • เป็น \ web \ app \ v2.1 \

วิธีนี้มีประโยชน์ดังต่อไปนี้:

• ในกรณีที่เวอร์ชันใหม่มีปัญหาคุณสามารถย้อนกลับไปที่ v2.0 ได้อย่างง่ายดาย
• ในการปรับใช้กับเซิร์ฟเวอร์จริงหรือเซิร์ฟเวอร์เสมือนหลายเครื่องคุณสามารถใช้สคริปต์ของคุณสำหรับการปรับใช้ไฟล์ เมื่อเซิร์ฟเวอร์ทั้งหมดมีเวอร์ชันใหม่แล้วคุณสามารถเปลี่ยนเมตาเบสของเซิร์ฟเวอร์ทั้งหมดได้พร้อมกันโดยใช้ Microsoft Web Deployment Tool

คุณสามารถทำให้การปรับใช้เป็นศูนย์เวลาหยุดทำงานบนเซิร์ฟเวอร์เดียวได้โดยใช้ Application Request Routing ใน IIS เป็นตัวจัดสรรภาระงานซอฟต์แวร์ระหว่างไซต์ IIS ภายในสองไซต์บนพอร์ตที่ต่างกัน สิ่งนี้เรียกว่ากลยุทธ์การปรับใช้สีน้ำเงินเขียวซึ่งมีเพียงหนึ่งในสองไซต์เท่านั้นที่พร้อมใช้งานในตัวจัดสรรภาระงานในช่วงเวลาใดเวลาหนึ่ง ปรับใช้กับไซต์ที่ "ไม่ทำงาน" อุ่นเครื่องและนำเข้าสู่ตัวโหลดบาลานเซอร์ (โดยปกติจะผ่านการตรวจสอบประสิทธิภาพการทำงานของคำขอการกำหนดเส้นทางของแอปพลิเคชัน) จากนั้นนำไซต์เดิมที่อัปเดตออกจาก "พูล" (อีกครั้ง โดยการตรวจสุขภาพล้มเหลว)

สามารถดูบทแนะนำแบบเต็มได้ที่นี่

เมื่อไม่นานมานี้ฉันได้ดำเนินการแก้ไขปัญหาที่ฉันคิดขึ้นมาคือการตั้งค่าไซต์สองไซต์ใน IIS และสลับไปมาระหว่างไซต์เหล่านี้

สำหรับการกำหนดค่าของฉันฉันมีเว็บไดเร็กทอรีสำหรับแต่ละไซต์ A และ B เช่นนี้: c: \ Intranet \ Live A \ Interface c: \ Intranet \ Live B \ Interface

ใน IIS ฉันมีสองไซต์ที่เหมือนกัน (พอร์ตเดียวกันการตรวจสอบความถูกต้อง ฯลฯ ) แต่ละไซต์มีพูลแอปพลิเคชันของตนเอง ไซต์หนึ่งกำลังทำงาน (A) และอีกไซต์หนึ่งหยุดทำงาน (B) รายการสดยังมีส่วนหัวของโฮสต์สด

เมื่อพูดถึงการนำไปใช้จริงฉันเพียงแค่เผยแพร่ไปยังตำแหน่งของไซต์ STOPPED เนื่องจากฉันสามารถเข้าถึงไซต์ B โดยใช้พอร์ตฉันจึงสามารถอุ่นไซต์ล่วงหน้าเพื่อให้ผู้ใช้รายแรกไม่ทำให้แอปพลิเคชันเริ่มทำงาน จากนั้นใช้ไฟล์แบตช์ฉันคัดลอกส่วนหัวของโฮสต์สดไปที่ B หยุด A และเริ่ม B

การใช้คลาส ServerManager ของ Microsoft.Web.Administration คุณสามารถพัฒนาตัวแทนการปรับใช้ของคุณเองได้

เคล็ดลับคือการเปลี่ยน PhysicalPath ของ VirtualDirectory ซึ่งส่งผลให้มีการสลับอะตอมออนไลน์ระหว่างเว็บแอปเก่าและใหม่

โปรดทราบว่าสิ่งนี้อาจส่งผลให้ AppDomains เก่าและใหม่ทำงานควบคู่กันไป!

ปัญหาคือวิธีซิงโครไนซ์การเปลี่ยนแปลงฐานข้อมูลเป็นต้น

โดยการสำรวจการมีอยู่ของ AppDomains ด้วย PhysicalPaths เก่าหรือใหม่จะสามารถตรวจพบเมื่อ AppDomain เก่ายุติลงและหาก AppDomain ใหม่เริ่มทำงาน

ในการบังคับให้ AppDomain เริ่มต้นคุณต้องส่งคำขอ HTTP (IIS 7.5 รองรับคุณสมบัติ Autostart)

ตอนนี้คุณต้องการวิธีบล็อกคำขอสำหรับ AppDomain ใหม่ ฉันใช้ชื่อ mutex - ซึ่งสร้างและเป็นเจ้าของโดยตัวแทนการปรับใช้รอโดย Application_Start ของเว็บแอปใหม่จากนั้นจึงปล่อยโดยตัวแทนการปรับใช้เมื่อทำการอัปเดตฐานข้อมูลแล้ว

(ฉันใช้ไฟล์เครื่องหมายในเว็บแอปเพื่อเปิดใช้งานพฤติกรรมการรอของ mutex) เมื่อเว็บแอปใหม่กำลังทำงานฉันจะลบไฟล์เครื่องหมาย

ตกลงเนื่องจากทุกคนลงคะแนนคำตอบที่ฉันเขียนไว้เมื่อปี 2008 * ...

ฉันจะบอกคุณว่าเราทำมันอย่างไรในปี 2014 เราไม่ได้ใช้เว็บไซต์อีกต่อไปเพราะเราใช้ ASP.NET MVC อยู่ในขณะนี้

แน่นอนว่าเราไม่จำเป็นต้องใช้ตัวโหลดบาลานเซอร์และเซิร์ฟเวอร์สองเครื่องในการทำเช่นนั้นก็ใช้ได้ดีถ้าคุณมีเซิร์ฟเวอร์ 3 เครื่องสำหรับทุกเว็บไซต์ที่คุณดูแล แต่มันเกินความจำเป็นทั้งหมดสำหรับเว็บไซต์ส่วนใหญ่

นอกจากนี้เรายังไม่พึ่งพาตัวช่วยล่าสุดจาก Microsoft - ช้าเกินไปและมีเวทมนตร์ที่ซ่อนอยู่มากเกินไปและมีแนวโน้มที่จะเปลี่ยนชื่อด้วย

นี่คือวิธีที่เราทำ:

1. เรามีขั้นตอนการสร้างโพสต์ที่คัดลอก DLL ที่สร้างขึ้นไปยังโฟลเดอร์ "bin-pub"

2. เราใช้ Beyond Compare (ซึ่งยอดเยี่ยมมาก **) เพื่อตรวจสอบและซิงค์ไฟล์ที่เปลี่ยนแปลง (ผ่าน FTP เนื่องจากได้รับการสนับสนุนอย่างกว้างขวาง) จนถึงเซิร์ฟเวอร์ที่ใช้งานจริง

3. เรามี URL ที่ปลอดภัยบนเว็บไซต์ที่มีปุ่มซึ่งคัดลอกทุกอย่างใน "bin-pub" ไปยัง "bin" (ทำการสำรองข้อมูลก่อนเพื่อเปิดใช้งานการย้อนกลับอย่างรวดเร็ว) ณ จุดนี้แอปจะรีสตาร์ทเอง จากนั้น ORM ของเราจะตรวจสอบว่ามีตารางหรือคอลัมน์ใดบ้างที่ต้องเพิ่มและสร้างขึ้นมา

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

ขั้นตอนการปรับใช้ทั้งหมดใช้เวลาตั้งแต่ 5 วินาทีถึง 30 นาทีขึ้นอยู่กับจำนวนไฟล์ที่มีการเปลี่ยนแปลงและจำนวนการเปลี่ยนแปลงที่ต้องตรวจสอบ

วิธีนี้ทำให้คุณไม่ต้องคัดลอกเว็บไซต์ทั้งหมดไปยังไดเร็กทอรีอื่น แต่มีเพียงโฟลเดอร์ bin นอกจากนี้คุณยังสามารถควบคุมกระบวนการได้อย่างสมบูรณ์และรู้ว่าอะไรกำลังเปลี่ยนแปลง

** เรามักจะมองเห็นการเปลี่ยนแปลงที่เรากำลังปรับใช้อย่างรวดเร็ว - เป็นการตรวจสอบอีกครั้งในนาทีสุดท้ายดังนั้นเราจึงรู้ว่าจะทดสอบอะไรและหากมีสิ่งใดขัดข้องเราพร้อม เราใช้ Beyond Compare เพราะช่วยให้คุณแตกต่างไฟล์ผ่าน FTP ได้อย่างง่ายดาย ฉันจะไม่ทำสิ่งนี้หากไม่มี BC คุณไม่รู้ว่าคุณเขียนทับอะไร

* เลื่อนลงไปด้านล่างเพื่อดู :( BTW ฉันไม่อยากแนะนำเว็บไซต์อีกต่อไปเพราะสร้างได้ช้ากว่าและอาจพังได้ไม่ดีกับไฟล์ temp ที่คอมไพล์แล้วครึ่งหนึ่งเราเคยใช้พวกเขาในอดีตเนื่องจากอนุญาตให้ใช้ไฟล์ทีละไฟล์ที่คล่องตัวมากขึ้น การปรับใช้แก้ไขปัญหาเล็กน้อยได้รวดเร็วมากและคุณสามารถเห็นสิ่งที่คุณกำลังปรับใช้อย่างชัดเจน (หากใช้ Beyond Compare แน่นอนมิฉะนั้นก็อย่าลืม)

วิธีการหยุดทำงานเป็นศูนย์เพียงวิธีเดียวที่ฉันสามารถนึกถึงการโฮสต์บนเซิร์ฟเวอร์อย่างน้อย 2 เซิร์ฟเวอร์

ฉันจะปรับแต่งคำตอบของ George เล็กน้อยดังต่อไปนี้สำหรับเซิร์ฟเวอร์เดียว:

1. ใช้ Web Deployment Project เพื่อคอมไพล์ไซต์ไว้ใน DLL เดียว
2. บีบไซต์ใหม่แล้วอัปโหลดไปยังเซิร์ฟเวอร์
3. แตกไฟล์ไปยังโฟลเดอร์ใหม่ที่อยู่ในโฟลเดอร์ที่มีสิทธิ์ที่ถูกต้องสำหรับไซต์ดังนั้นไฟล์ที่คลายซิปจะสืบทอดสิทธิ์อย่างถูกต้อง (อาจเป็น e: \ web ที่มีโฟลเดอร์ย่อย v20090901, v20090916 เป็นต้น)
4. ใช้ IIS Manager เพื่อเปลี่ยนชื่อโฟลเดอร์ที่มีไซต์
5. เก็บโฟลเดอร์เก่าไว้สักครู่เพื่อให้คุณสามารถสำรองไปยังโฟลเดอร์นั้นได้ในกรณีที่เกิดปัญหา

ขั้นตอนที่ 4 จะทำให้กระบวนการของผู้ปฏิบัติงาน IIS รีไซเคิล

นี่เป็นเพียงการหยุดทำงานเป็นศูนย์หากคุณไม่ได้ใช้เซสชัน InProc ใช้โหมด SQL แทนถ้าคุณทำได้ (ดีกว่านั้นให้หลีกเลี่ยงสถานะเซสชันโดยสิ้นเชิง)

แน่นอนว่ามันมีส่วนเกี่ยวข้องมากขึ้นเล็กน้อยเมื่อมีการเปลี่ยนแปลงเซิร์ฟเวอร์และ / หรือฐานข้อมูลหลายตัว ....

หากต้องการขยายคำตอบของ sklivvz ซึ่งอาศัยการมีโหลดบาลานเซอร์บางประเภท (หรือเพียงแค่สำเนาสแตนด์บายบนเซิร์ฟเวอร์เดียวกัน)

1. กำหนดทิศทางการรับส่งข้อมูลทั้งหมดไปยังไซต์ / เซิร์ฟเวอร์ 2
2. หรือรอสักครู่เพื่อให้แน่ใจว่ามีผู้ใช้จำนวนน้อยที่สุดที่มีเวิร์กโฟลว์ที่รอดำเนินการในเวอร์ชันที่ปรับใช้
3. ปรับใช้กับไซต์ / เซิร์ฟเวอร์ 1 และอุ่นเครื่องให้มากที่สุด
4. ดำเนินการย้ายฐานข้อมูลแบบธุรกรรม (พยายามทำให้เป็นไปได้)
5. กำหนดทิศทางการรับส่งข้อมูลทั้งหมดไปยังไซต์ / เซิร์ฟเวอร์ 1 ทันที
6. ปรับใช้กับไซต์ / เซิร์ฟเวอร์ 2
7. การรับส่งข้อมูลโดยตรงไปยังทั้งไซต์ / เซิร์ฟเวอร์

เป็นไปได้ที่จะแนะนำการทดสอบควันเล็กน้อยโดยการสร้างสแนปชอต / สำเนาฐานข้อมูล แต่ก็ไม่สามารถทำได้เสมอไป

หากเป็นไปได้และจำเป็นให้ใช้ "ความแตกต่างของการกำหนดเส้นทาง" เช่น URL ของผู้เช่าที่ต่างกัน: s (customerX.myapp.net) หรือผู้ใช้ที่แตกต่างกันเพื่อปรับใช้กับกลุ่มหนูตะเภาที่ไม่รู้ตัวก่อน ถ้าไม่มีอะไรล้มเหลวปล่อยให้ทุกคน

เนื่องจากเกี่ยวข้องกับการย้ายฐานข้อมูลการย้อนกลับไปยังเวอร์ชันก่อนหน้าจึงเป็นไปไม่ได้

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

นี่คือวิธีที่ฉันทำ:

ข้อกำหนดขั้นต่ำของระบบแน่นอน:
1 เซิร์ฟเวอร์พร้อม

• 1 ตัวโหลดบาลานเซอร์ / พร็อกซีย้อนกลับ (เช่น nginx) ทำงานบนพอร์ต 80
• 2 ASP.NET-Core / mono reverse-proxy / fastcgi chroot-jails หรือ docker-container ที่ฟังบนพอร์ต TCP 2 พอร์ตที่แตกต่างกัน
  (หรือแม้แต่แอปพลิเคชั่น reverse-proxy สองตัวบนพอร์ต TCP 2 พอร์ตที่แตกต่างกันโดยไม่มี Sandbox)

ขั้นตอนการทำงาน:

เริ่มการทำธุรกรรม myupdate

try
    Web-Service: Tell all applications on all web-servers to go into primary read-only mode 
    Application switch to primary read-only mode, and responds 
    Web sockets begin notifying all clients 
    Wait for all applications to respond

    wait (custom short interval)

    Web-Service: Tell all applications on all web-servers to go into secondary read-only mode 
    Application switch to secondary read-only mode (data-entry fuse)
    Updatedb - secondary read-only mode (switches database to read-only)

    Web-Service: Create backup of database 
    Web-Service: Restore backup to new database
    Web-Service: Update new database with new schema 

    Deploy new application to apt-repository 
    (for windows, you will have to write your own custom deployment web-service)
    ssh into every machine in array_of_new_webapps
    run apt-get update
    then either 
    apt-get dist-upgrade
    OR
    apt-get install <packagename>
    OR 
    apt-get install --only-upgrade <packagename>
    depending on what you need
    -- This deploys the new application to all new chroots (or servers/VMs)

    Test: Test new application under test.domain.xxx
    -- everything that fails should throw an exception here
    commit myupdate;

    Web-Service: Tell all applications to send web-socket request to reload the pages to all clients at time x (+/- random number)
    @client: notify of reload and that this causes loss of unsafed data, with option to abort 

    @ time x:  Switch load balancer from array_of_old_webapps to array_of_new_webapps 
    Decomission/Recycle array_of_old_webapps, etc.

catch
        rollback myupdate 
        switch to read-write mode
        Web-Service: Tell all applications to send web-socket request to unblock read-only mode
end try 

ฉันขอแนะนำให้เก็บไฟล์เก่าไว้ที่นั่นและเขียนทับ ด้วยวิธีนี้การหยุดทำงานจะถูก จำกัด ไว้ที่เวลาในการเขียนทับไฟล์เดียวและมีเพียงไฟล์เดียวที่หายไปในแต่ละครั้ง

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