Go/Ocean
Go/Ocean
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Automated Deployment #13

New Issue
Closed
opened 2014-04-26 10:16:07 +00:00 by thorsten · 2 comments
thorsten commented 2014-04-26 10:16:07 +00:00 (Migrated from devops.tsommer.org)
Copy Link

It would be possible to provide a full-automated deployment:

  • The administrator stores a new release into the GridFS by using the filename "release"! TODO: What happens, if the cluster is mixed UNIX and Windows servers and/or mixed 64/32 bits, etc.? Then, we would need different builds...
  • Running servers are polling these files every ~5 minutes
  • The current release state of every node inside the cluster is tracked by a own database collection. ~We need a unique hostnames for this!~ Every IP address inside the whole data center must be unique!
  • After an node has updated, the release information in the collection is updated.
  • At the startup, check if there is the ocean-upgrade application present. If not, do not run the automated upgrade thread for this machine!
  • After a node find a new release:
    • The current process downloads the new release and stores it in his root folder.
    • The current process starts the ocean-upgrade application and provides the current PID and his own application / executable name.
    • ocean-upgrade will shutdown the server, delete the last release, rename the new release and boots up the new release! TODO: Let say the node runs on FreeBSD: Here we need to execute something like "services XYZ start", etc. Maybe the necessary command or method should be configurable for every node?!
    • The application ocean-upgrade stops!
It would be possible to provide a full-automated deployment: - [ ] The administrator stores a new release into the GridFS by using the filename "release"! **TODO:** What happens, if the cluster is mixed UNIX and Windows servers and/or mixed 64/32 bits, etc.? Then, we would need different builds... - [ ] Running servers are polling these files every ~5 minutes - [ ] The current release state of every node inside the cluster is tracked by a own database collection. ~We need a unique hostnames for this!~ Every IP address inside the whole data center must be unique! - [ ] After an node has updated, the release information in the collection is updated. - [ ] At the startup, check if there is the ocean-upgrade application present. If not, do not run the automated upgrade thread for this machine! - [ ] After a node find a new release: - [ ] The current process downloads the new release and stores it in his root folder. - [ ] The current process starts the ocean-upgrade application and provides the current PID and his own application / executable name. - [ ] ocean-upgrade will shutdown the server, delete the last release, rename the new release and boots up the new release! **TODO:** Let say the node runs on FreeBSD: Here we need to execute something like "services XYZ start", etc. Maybe the necessary command or method should be configurable for every node?! - [ ] The application ocean-upgrade stops!
thorsten commented 2014-06-05 13:50:31 +00:00 (Migrated from devops.tsommer.org)
Copy Link
  • See also #14 => The master server must switch while upgrading 2 times.
- [ ] See also #14 => The master server must switch while upgrading 2 times.
thorsten commented 2022-04-23 15:34:03 +00:00 (Migrated from devops.tsommer.org)
Copy Link

changed the description

changed the description
thorsten (Migrated from devops.tsommer.org) closed this issue 2022-04-23 15:34:03 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
bug

   
change

   
check

   
Comp::Backend

   
Comp::Database

   
Comp::ICCC

   
Comp::Logging

   
Comp::Sessions

   
Comp::System

   
Comp::Users

   
enhancement

   
note

   
outdated

Outdated since Ocean is no longer maintained

  
question

   
Ready2Test

   
security

   
todo

   
wontfix
No Label
bug
change
check
Comp::Backend
Comp::Database
Comp::ICCC
Comp::Logging
Comp::Sessions
Comp::System
Comp::Users
enhancement
note
outdated
question
Ready2Test
security
todo
wontfix
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Go/Ocean#13
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?