Feat/add network management#3774
Conversation
- Added components for handling and displaying Docker networks, including creation, editing, and listing of networks. - Introduced a new API router for network operations, integrating with the database schema for network management. - Updated the sidebar layout to include a link to the networks dashboard, ensuring user access to network features. - Created necessary database migrations for the network table and its associated types. - Enhanced the dashboard layout to support the new network management interface.
- Eliminated the unused DOKPLOY_SERVER_VALUE constant from the network handling component. - Updated the default serverId to undefined in the network form values and adjusted related logic to ensure compatibility with cloud environments. - Enhanced server validation in the createNetwork function to require a serverId when in cloud mode, improving error handling for network creation.
- Introduced a new column "networkIds" of type text[] with a default value of an empty array to the application, compose, mariadb, mongo, mysql, postgres, and redis tables. - Updated the application and compose schemas to include the new networkIds field in their respective TypeScript definitions. - Added corresponding entries in the migration journal and created a snapshot for version 7 to reflect these changes.
- Deleted the SQL files for the "network" table and its associated constraints, as well as the snapshots for versions 0146 and 0147, to clean up the database schema and remove unused components. - Updated the migration journal to reflect these deletions, ensuring the database remains consistent and manageable.
| export const removeNetwork = async (networkId: string) => { | ||
| const [deleted] = await db | ||
| .delete(network) | ||
| .where(eq(network.networkId, networkId)) | ||
| .returning(); | ||
|
|
||
| if (!deleted) { | ||
| throw new TRPCError({ | ||
| code: "NOT_FOUND", | ||
| message: "Network not found", | ||
| }); | ||
| } | ||
|
|
||
| return deleted; | ||
| }; |
There was a problem hiding this comment.
Deletes from database but doesn't remove the actual Docker network via docker.getNetwork(networkName).remove(). This will leave orphaned networks in Docker.
| export const removeNetwork = async (networkId: string) => { | |
| const [deleted] = await db | |
| .delete(network) | |
| .where(eq(network.networkId, networkId)) | |
| .returning(); | |
| if (!deleted) { | |
| throw new TRPCError({ | |
| code: "NOT_FOUND", | |
| message: "Network not found", | |
| }); | |
| } | |
| return deleted; | |
| }; | |
| export const removeNetwork = async (networkId: string) => { | |
| const networkData = await findNetworkById(networkId); | |
| const docker = await getRemoteDocker(networkData.serverId ?? null); | |
| await docker.getNetwork(networkData.name).remove(); | |
| const [deleted] = await db | |
| .delete(network) | |
| .where(eq(network.networkId, networkId)) | |
| .returning(); | |
| if (!deleted) { | |
| throw new TRPCError({ | |
| code: "NOT_FOUND", | |
| message: "Network not found", | |
| }); | |
| } | |
| return deleted; | |
| }; |
| export const updateNetwork = async (input: typeof apiUpdateNetwork._type) => { | ||
| const { networkId, ...rest } = input; | ||
| const [updated] = await db | ||
| .update(network) | ||
| .set(rest) | ||
| .where(eq(network.networkId, networkId)) | ||
| .returning(); | ||
|
|
||
| if (!updated) { | ||
| throw new TRPCError({ | ||
| code: "NOT_FOUND", | ||
| message: "Network not found", | ||
| }); | ||
| } | ||
|
|
||
| return updated; | ||
| }; |
There was a problem hiding this comment.
Updates database record but doesn't update the actual Docker network. Docker networks are immutable after creation - most properties cannot be changed. Consider either:
- Preventing updates to Docker-related properties (driver, IPAM, etc.), or
- Recreating the network if critical properties change
Note: Only the database name can be updated safely without affecting Docker.
| if (IS_CLOUD) | ||
| if (!input.serverId) { | ||
| throw new TRPCError({ | ||
| code: "BAD_REQUEST", | ||
| message: "Server is required", | ||
| }); | ||
| } |
There was a problem hiding this comment.
Missing braces - the if (!input.serverId) check executes regardless of IS_CLOUD value.
| if (IS_CLOUD) | |
| if (!input.serverId) { | |
| throw new TRPCError({ | |
| code: "BAD_REQUEST", | |
| message: "Server is required", | |
| }); | |
| } | |
| if (IS_CLOUD) { | |
| if (!input.serverId) { | |
| throw new TRPCError({ | |
| code: "BAD_REQUEST", | |
| message: "Server is required", | |
| }); | |
| } | |
| } |
| {!isCloud && ( | ||
| <SelectItem value={undefined}> | ||
| Dokploy server | ||
| </SelectItem> | ||
| )} |
There was a problem hiding this comment.
SelectItem with value={undefined} may not work as expected in React. Consider using an empty string or a sentinel value like "__local__".
- Added a new "network" table with various attributes including networkId, name, driver, and constraints for organizationId and serverId. - Introduced a custom ENUM type "networkDriver" for network drivers. - Updated existing tables (application, compose, mariadb, mongo, mysql, postgres, redis) to include a new "networkIds" column of type text[]. - Created a snapshot for version 7 to reflect these schema changes in the database.
- Updated the createNetwork function to ensure serverId is required when in cloud mode, improving error handling for network creation. - Added braces for clarity in the conditional statement, enhancing code readability.
|
Why not mention PR #2811 to at least warn that the feature has been completely redone? |
|
Curious if this is something actively being worked on? This feels like a huge missing piece for production use-cases, as well as competing with other PaaS. So far love Dokploy, just wondering where this lives in the priority? |
|
Is there an approximate merge date for this PR or the original PR (#2811)? I agree with @Baker that this feature is missing and important in a product like Dokploy, especially in production. It could make a huge difference compared to some other similar products. So, whether it's this PR or the one chichi13 submitted (the work he did is honestly amazing), is there any plan to address this? |
- Deleted the SQL file for the "network" table and its associated constraints, as well as the snapshot for version 0146, to clean up the database schema. - Updated the migration journal to reflect these deletions, ensuring consistency in the database structure.
- Introduced a new ENUM type "networkDriver" and created the "network" table with various attributes for network management. - Added "networkIds" column to multiple existing tables (application, compose, mariadb, mongo, mysql, postgres, redis) to support network associations. - Established foreign key constraints for "organizationId" and "serverId" in the "network" table to ensure referential integrity. - Updated migration journal and added a new snapshot for version 0166 to reflect these changes.
|
Up please |
|
@Siumauricio any updates on this? |
|
Up please |
…gnore - Deleted the SQL file and snapshot related to the "network" management schema, cleaning up the database structure. - Updated the migration journal to reflect these deletions. - Added .playwright-* to .gitignore to exclude Playwright test files from version control.
- Introduced a new SQL file defining the "network" type and its associated table structure. - Added "networkIds" column to multiple application tables for network association. - Established foreign key constraints for the "network" table linking to "organization" and "server" tables. - Updated migration journal and added a new snapshot for versioning.
- Updated the ShowNetworks component to improve the layout and user experience. - Introduced a new Pencil icon for editing networks and added a Badge component for displaying network drivers. - Refactored loading and empty state handling for better visual feedback. - Modified the API query to include server details for each network, enhancing the data returned for better context.
…ogic - Replaced zodResolver with standardSchemaResolver for improved schema validation. - Added new toggle options for network settings, enhancing user interface clarity. - Refactored network creation and update logic to streamline payload handling. - Updated network form schema to remove default values, ensuring explicit user input. - Introduced SERVER_LOCAL sentinel for local Dokploy server identification.
- Simplified the network form schema by removing unnecessary fields and enforcing validation rules for IP settings. - Updated the HandleNetwork component to eliminate the edit functionality, focusing on network creation only. - Improved the ShowNetworks component by adding a delete action for network management, enhancing user experience. - Introduced a new SQL migration for the network schema, establishing necessary constraints and types. - Cleaned up the API by removing the update network functionality, reflecting the immutable nature of Docker networks.
…actions - Introduced a new ShowNetworkConfig component for displaying detailed Docker network configuration. - Integrated ShowNetworkConfig into the ShowNetworks component, allowing users to view network details directly. - Updated the layout of network actions for improved user experience and accessibility. - Enhanced the API to support network inspection functionality, providing necessary data for the new component.
…synchronization - Added server filtering capability to the dashboard, allowing users to manage networks specific to selected servers. - Introduced SyncNetworks component for synchronizing Docker networks with Dokploy, enabling import of new networks and cleanup of stale records. - Updated HandleNetwork and ShowNetworks components to support server-specific operations, improving user experience and functionality. - Enhanced API to support network synchronization and importing, ensuring accurate data handling for network management.
…e synchronization - Added a new API endpoint for recreating Docker networks that have been removed, allowing users to restore networks directly from the Dokploy interface. - Updated the ShowNetworks and SyncNetworks components to include options for recreating networks, improving user management capabilities. - Enhanced the network synchronization process to better handle stale records, providing users with clear actions for network maintenance. - Refactored network creation logic to streamline the process and ensure consistency across network management operations.


What is this PR about?
Please describe in a short paragraph what this PR is about.
Checklist
Before submitting this PR, please make sure that:
canarybranch.Issues related (if applicable)
Screenshots (if applicable)
Greptile Summary
This PR adds Docker network management functionality to Dokploy, enabling users to create, view, and manage Docker networks through the UI. The implementation includes:
networkdatabase table with support for Docker network properties (driver types, IPAM config, IPv4/IPv6 settings)networkIdscolumns added to application and database service tables for future network assignmentCritical Issues Found:
removeNetwork()only deletes the database record but doesn't remove the actual Docker network, which will leave orphaned networksupdateNetwork()only updates the database without modifying the Docker network (most Docker network properties are immutable after creation)IS_CLOUDconditional causes server validation to execute incorrectlyConfidence Score: 2/5
removeNetworkandupdateNetworkfunctions that don't synchronize with Docker, and a syntax error in the cloud validation logic. These issues will lead to orphaned Docker networks and database/runtime inconsistencies.packages/server/src/services/network.tsrequires immediate attention for Docker API integration in remove/update operationsLast reviewed commit: a8f941b