livecycle / preevy Goto Github PK

Instead of setting up Preevy, then installing the Livecycle SDK - create a simple way to add Livecycle to Preevy environment for collaboration.

Can be exposed by 'compose-tunnel-agent' which might worth changing to simply Preevy agent.
Such metadata can be:

• Time of creation
• Provider flags (size, region)
• Git Context
• Current services/tunnels (already implemented partly)
• Plugins metadata

This data can be used by Preevy widget/dashboard

• Driver test suite (for cloud provider implementation)
• Basic unit test coverage

Support a way to configure the default service to run the application in the docker-compose file.
For example: x-preevy-default-service: true

Using preevy down --id="myenv" should be able to destroy the environment in similar fashion to docker-compose -p

what's wrong with the documentation?

By disabling blank issues, we will prevent issues without enough information or spammy issues.
We can add a miscellaneous template that will be used for anything else that does not fit the current templates.

If you like this idea, I'd like to work on this. 🙂

Add screenshots

I don't think this applies here.

Record

• I agree to follow this project's Code of Conduct

preevy --help should show all global flags (e.g, --debug)

Initial implementation will be based on http basic authentication.

• Support for declaring "private" services
• Support for authentication using tunneling-key based authentication

What feature?

Currently, some of the package scripts in our package.json files are not compatible with all operating systems. To ensure seamless development across different platforms, we need to update the scripts to be cross-platform compatible.

Affected script:
clean The current implementation uses rm -rf to remove directories, which is not compatible with Windows systems.

Describe the solution you'd like

We should switch to a cross-platform solution like rimraf.

Describe alternatives you've considered

No response

Additional context

No response

Add screenshots

No response

Record

• I agree to follow this project's Code of Conduct

In narrow terminals, preview environments can be trimmed, which result in broken links (when clicking or copying):

We should take into consideration the level of error verbosity and the type of error to remove noise from the CLI output.
For example, error in mismatching or invalid args/flags shouldn't print out a stack trace.

Error: process exited with code 1
at ChildProcess. (/Users/yshayyaacobi/.nvm/versions/node/v16.20.0/lib/node_modules/preevy/src/lib/child-process.ts:49:16)
at ChildProcess.emit (node:events:513:28)
at Process.ChildProcess._handle.onexit (node:internal/child_process:293:12)

This feature will allow users to use their existing k8s infrastructure as backbone for Preevy environments.
Initial implementation can create a pod with support for nested Docker (probably need to be privileged or require additional CRI runtime), port-forwarding can be done with kubectl.
Persistent volume might also be interesting to add in the future to support "suspending" an environment.

To ensure we're using the right cluster, we should initialize the profile with kube-context (while still allowing users to override it in up/down command)

Initial functionality:

• Show all services and links
• Show current git context (branch/pr)

• Implement machine driver for Azure (probably based on VMs
• Implement store based on Azure blob storage for profile store

Currently, preevy print this error:

Error: spawn docker ENOENT
    at Process.ChildProcess._handle.onexit (node:internal/child_process:283:19)
    at onErrorNT (node:internal/child_process:476:16)
    at processTicksAndRejections (node:internal/process/task_queues:82:2

It's very aggressive and we should print a friendlier message

maybe redirect to the docs site?

currently, we have only two issue templates we can add a few templates such as style, docs etc.

• we need to use the .yml format issue template like these.
  

features if we use the .yml format

• we can add multiple textboxes, checkboxes, tags etc.
  

I want to work on this issue

• Sample full stack apps
• CLI sample (wrapped with ttyd or other similar tool)

The main README says:
In AWS, it could be by using aws login or aws configure

the AWS cli doesn't contain any login command.

what am i missing?

We should be able to support the session for:

• Support flows different from basic authentication
• Improving the experience of the login between different environments/services (no need to re-login)
• Allow to create a session without passing the authorization header the can conflict with internal app authorization header and doesn't work properly when using websockets

Currently, loading plugins is dependent on docker-compose and Preevy crashes when there's no docker client.
Ideally, we should be able to run without plugins most command (maybe add warning), and the behavior should be handled more gracefully.

Bug description?

Subdomain is limited to 63 characters, we should trim to the characters to support valid URLs.
Implementation can be done in tunnel server or Preevy/compose tunnel agent.
In both cases, we should pay attention to the CLI functionality of predicting the URL for injecting env variables:
https://preevy.dev/recipes/service-discovery

We should also think if we want to truncate the entire subdomain url, or set a size limit for each fragment:
https://{service}-{[port]}-{env-id}-{client-id}

Additional context

Current workaround: use the --id flag in up to create a shorter env identifier or use shorter branch names.

Record

• I agree to follow this project's Code of Conduct

Can be something like:
copying ${volume.source}............done

Currently, preevy teardown after simple commands like ls,profile * takes too much time

using the CLI to show logs show no prompt.
after executing up command, trying to show logs with a wrong service name does nothing.

Steps to reproduce:

• preevy up
• preevy logs any-text-you-want
• nothing happens, no error, no logs.

using debug level shows that socket is closed.

• if there is no env up or after 'preevy down' command, the output is ok ( Error: No machine found for envId wekan-master)

Currently, if you'll try to deploy with the GCP driver while your branch name contains Uppercase characters, you'll get the following error

Run echo "/home/runner/work/_actions/livecycle/preevy-up-action/v1.2.0" >> $GITHUB_PATH
Run # Convert the docker-compose-yaml-paths input to an env var
Docker file paths docker-compose.yml
Running Preevy with files: -f docker-compose.yml -f docker-compose.dev.yml 
Using environment ID: preevy-saas-eliyaenvironmentsUI
- Creating Google Cloud machine
✖ Creating Google Cloud machine: Creating from existing snapshot
    Error: Invalid value for field 'resource.labels': ''. Label value 
    'preevy-saas-eliyaenvironmentsUI' violates format constraints. The value 
    can only contain lowercase letters, numeric characters, underscores and 
    dashes. The value can be at most 63 characters long. International 
    characters are allowed.
    Code: 3

Possible solution: lowercase the resource label value.

Tunnel server is a standalone service, it might be worth decoupling it from the CLI

At present, Preevy tunnel only forwards HTTP traffic, and HTTPS is handled by an external service that performs TLS termination. The tunnel server uses the HTTP host header to route traffic to the appropriate service.

If TLS support is added to the tunnel server, Preevy will be able to route non-HTTP traffic to the correct host using Server Name Indication (SNI). Specific protocol manipulation, such as rewriting headers, can be accomplished by explicitly specifying the channel type or using Application-Layer Protocol Negotiation (ALPN).

This new feature will enable users to directly connect to their non-HTTP services, such as databases, provided that their client supports TLS and uses SNI.

Is your feature request related to a problem? Please describe.
An easy way to set up Preevy up/down flows in GH actions.
Currently, it requires installing Preevy with npm -g or using npx.

Describe the solution you'd like
A GH action that wrap the up/down parameters.
Profile is specified as parameter and importing is done automatically.

uses: preevy/action@v1
with:
     profile-url: "s3://aabcd"
     command: up
     args: 

Describe alternatives you've considered
It's possible to remove NPM dependency/installation by packing Preevy CLI as a Docker image, and support environment variable for profile URL, but there's a drawback which it's not trivial to get the cloud provider context when running this way.

when using preevy up, the following text appears:
'Using envId: xxx'
replace it with something more readable like
'Using environment id: xxx'

When doing service-service communication, Preevy can work well due to compose service discovery.
However, when using a frontend that utilize the exposed port for connecting to backend (can be common in dev environments), it's a bit tricky since we need to replace the url with tunneling url which we don't know about yet.

One way to solve it, is by injecting/resolving env variables of tunneling url in compose normalization. (so it can affect both build args, and environment)

For example:

services:
     api:
           ....
           ports:
           - 9005:3000
     fronend:
          environment:
          - API_URL=http://localhost:9005

This could be a common setup.

With Preevy, it could be something like:

services:
     api:
           ....
           ports:
           - 9005:3000
     fronend:
          environment:
          - API_URL={PREEVY_BASE_URI_API_3000:-http://localhost:9005}

In the future, we can enhance this by supporting inference of this configuration automatically and replacing all static http://localhost:xx variables' values based on public ports definitions.

Currently, it uses the right disk which have litttle disk space.

For example, use ssh to go into the VM and use the internal docker commands to find out what's wrong

• Cover debug with preevy ssh
• Cover authorization scenarios for frontend apps (domain origin in such)

Currently, preevy exposes all services by default

Tunneling server should support additional JWT issuers

What feature?

When using preevy up or other commands, it can take several seconds until we see the output due to connectivity with cloud providers. (for example, downloading profile)
We can improve this experience by adding console messages that log these interactions.

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional context

No response

Add screenshots

No response

Record

• I agree to follow this project's Code of Conduct

When using preview to create environment for loki using this compose file mange to build and run, but grafana fails to communicate with loki (getting 500s in the network logs)

After I tried to use preevy up command to deploy my current changes, preevy created machines on AWS lightsail without env id and driver name was not correct.

Current package names are a bit confusing, suggestion:
standalone-proxy -> tunneling, or tunneling-service is more fitting to the context.
docker-proxy -> compose-tunneling-agent or docker-tunneling-agent as it basically a client daemon that connect to a tunneling service based on compse/docker state

When this service is accessed directly, users will be able to see the list of all the environment services. (can be the compose-tunnel)

Add a simple way to get to the latest Preevy environment of a PR, ideally using a Preevy bot adding the link as a comment in the PR

Implement a profile storage for azure blob storage.

Should be similar to other implementations:

• GS - https://github.com/livecycle/preevy/blob/main/packages/driver-gce/src/fs/index.ts
• S3 - https://github.com/livecycle/preevy/blob/main/packages/driver-lightsail/src/fs/index.ts

Registration is done here:
https://github.com/livecycle/preevy/blob/main/packages/cli/src/fs.ts

Url format should follow conventions of golang cloud sdk:
https://gocloud.dev/howto/blob/#azure

Currently, only the init or create command allow to set default flags (such as region) and they are only used on initialization of a profile.